More on curly quotes–Code Samples are Clean

Unfortunately the curly quotes crept into the downloadable code samples as well as the ebook. Unfortunately, I can’t get the ebook fixed, but I have gone through and done a global search and replace on all the code sample files to put the curly quotes back to straight quotes.

I think I’m going to dream of curly quotes tonight. 🙂 Thank goodness for search and replace!

Curly quotes, straight quotes, and copy/pasting from the ebook

I am working on an update of the ebook for the extended ebook version (includes videos!) and I would love it if anyone has any errors to report. If you can get them to me (comments, emails, carrier pigeon, whatever!) before the end of March I can get them corrected for the next version.

One thing I discovered today is that if you copy and paste code samples directly from the ebook, you may have trouble. Word, as some of you may know, likes curly quotes like “ and ” but PHP (and JavaScript and HTML and almost every other code type) does not like curly quotes. When I wrote the book I turned off curly quotes because of this, but my editors have them on by default, and despite my best efforts some have slipped into the code samples.

This shouldn’t matter if you’re just copying the code by typing it in or if you use the samples I’ve added to this site (note, not the PDFs). But if you copy and paste from an ebook version, you may run across this problem. It’s especially annoying as these quotes are impossible to see in many font faces.

I recommend, if you do copy code from the ebook versions, that you do a search and replace across it, replacing and with ".

I’m making a note of this in the code samples as I find them in the ebook, but it’s very hard to see and I probably won’t find all of them. (I wonder if I can search and highlight in the PDF?? hmmmm…)

I know it’s a problem in the code at the top of page 76 (in the “Making Rollovers with jQuery” section). It should read:

  $("#link1 img").hover(
    function() {
      this.src = this.src.replace("_off","_on");
    },
    function() {
      this.src = this.src.replace("_on","_off");
    }
  );
});
</script>
</head>
<body>
<a id="link1" href="#"><img src="images/get-scifi_off.png" alt="Get Science
Fiction!"></a>
</body>
</html>

Honestly? I really hate Word. I’d rather write NOTHING in that editor, because it causes me much more grief than it solves. I’m sure my editors would disagree.

Degrees? Radians? Blergh — Errors in the CANVAS Chapter

So, I was doing some CANVAS work today creating circles. And I know that the start and end points of my circle drawings are written in radians, and I know that to get a radian from a degree, I need to convert from degrees with the calculation:

var radians = (Math.PI/180) * degrees;

But as I was doing the work, the circles weren’t acting like I expected them to. I’m not sure how I missed this during my edits, but in Hour 10: Drawing with the HTML5 Canvas Element (which is one of the chapters available free from this site) I stated that in degrees 0° is noon on a clock, but that is wrong.

In fact, 0° is 3 o’clock. But what is more telling is that degrees then move counter-clockwise around the clock face. So 90° is noon, 180° is 9 o’clock, 270° is 6 o’clock and so on.

The other error is the implication that 0 radians is a different location than 0°. But in fact, if you do the math, you will see that they are exactly the same. Plugging it into the above formula, you get:

var radians = (Math.PI/180) * 0;
var radians = 0;

This may not seem like a big deal if all you ever draw are complete circles. But if you’re trying to draw a half circle starting at 3 o’clock and ending at 9 o’clock, you might be very frustrated if you think that would be 90° to 270°. You would still get a half circle, but it would be on the right side of the clock rather than the bottom of the clock.

Direction of the Arc

Another error that I found regarding drawing circles on canvas regards the direction the pointer travels when drawing the circle or arc. In the book I stated that the final value of the arc method was the direction. This is correct, but the values I listed were wrong. It should say that true means counterclockwise and false means clockwise.

The code that is included in hour 10 does work correctly, it was just how the code was described that was incorrect.

I hope these errors didn’t confuse anyone, I will make sure to get this corrected in future editions.

Errata Specifics

Page 175
in the second paragraph of the “Drawing Circles” section

“…and finally the direction to draw either clockwise (true) or counterclockwise (false).”

Should read:

“…and finally the direction to draw either counterclockwise (true) or clockwise (false).”

Page 175
in the “By the Way” section titled  “How to Find Start and End Points for Circles and Arcs”

Radians do not have the same starting point as degrees (in degrees 0° is noon, but in radians it is not).

Should read:

“Radians are measured differently than degrees. 1 radian equals about 57.3 degrees, and there are about 6 radians in every circle.”

Hour 11 error found

In Hour 11, Fonts and Typography in HTML5, there is an error in the hyphenation style properties list.

The code for hyphenate-limit-last on page 195 should read:

hyphenate-limit-last: all;

Rather than hyphenation-limit-last.

And in that same hour, The Guillemets in Table 11.1 are printed as << and >>. This is also incorrect. Guillemets are a different character from < and >. They should be displayed in the book as « and ».

Blink and you missed it. TIME element back in the HTML5 spec

After a large uproar by designers and developers last week when they removed the HTML5 TIME element, the W3C recanted and put it back in the spec. So you don’t have to replace TIME with DATA, but you can if you want to.

This corrects last week’s errata post. The book still contains the TIME element, but does not contain the DATA element.

What’s really great is that this shows that the W3C is listening to us. So if there is some other problem with the HTML5 spec, don’t be shy—let them know. If enough agree, your change may happen!

The TIME Element Has Been Removed in Favor of DATA

As of October 29th there is a new element in HTML5: DATA. The DATA element is for defining content that has both human- and computer-readable data. Some examples of this are:

  • Dates and times
  • Numbers
  • Colors
  • Money

Each of these can be written in a way that a human will understand, while a computer might not. For example, a date can be written December 16th, Dec 16, 12/16/11, 16 December, and many other ways. While it is possible to teach computers to know that all those things are dates and what they meant. So you can set the value of a date on a data element with a standard format that computers can read.

<data value=“2011-12-16”>December 16th</data>

With the DATA element and its required attribute value you can define data for microformats and microdata as well as for scripts on your web page. The content displays in a format that humans appreciate and the value attribute has the content in a format that computers can read and use.

The DATA Element Replaces the TIME Element

In the same revision to the HTML5 specification that brought us the DATA element, it also removed the TIME element from the specification. While you might be disappointed, this is really a good thing. The TIME element was limited only to date and time formats and as such had a limited scope. With the DATA element you can mark up all sorts of things that can be defined in both human- and computer-readable formats, you are not just limited to dates and times.

How This Affects the Book

I submitted my final revision of the book on October 25, 2011—four days before this change went into effect. The book covers the TIME element, but does not include the DATA element.