Invited Expert

I put in an application to be considered as an invited expert by the W3C in response to Jeff Schiller’s work to encourage participation in the SVG Interest Group. I do like SVG and am interested in promoting SVG, but the whole process of having to submit an application to be considered to be an invited expert just to participate in an interest group was uncomfortable. I’ve never been one to call myself an “expert”, and I don’t classify myself with other “invited experts” I’ve seen in other interest groups.

The W3C has to change how it does business. Consider the process just to join this group to promote SVG—something you would think the W3C would welcome with open arms:

  1. First you have to identify whether you work for an organization already in the W3C. I assume if you’re an individual who wants to participate without joining as part of your company’s effort, you’re out of luck.
  2. If you’re not part of a W3C organization, you’re asked to consider whether the company you work for might be interested in joining the W3C, before joining as an individual.
  3. If you stubbornly persist in being an individual to this point, you’re then greeted with the Policy for Approval of Invited Experts, where we’re told that normally the committee Chair and Contact would meet with us, first, before submitting the application. Then the application is reviewed, and if the “invited expert” would need to have access to W3C members-only area, another internal approval process must be conducted.
  4. At some point in time, within ten business days, my application may, or may not, be approved. If it is approved, though, anything I do associated with this effort immediately becomes property of the W3C.

In addition, I can only remain a member of good standing if I don’t miss any more than one face-to-face meeting in three, even if I have to pay my own way to Boston, where one assumes such meetings take place. Of course, if the Chair is feeling generous, I may be excused this requirement. However, I must refrain from “offending” any other member of the W3C; criteria I’m sure to have already failed, just by writing this post.

No, I’m not invited expert material. I’m just a tech who likes SVG and wants to see its popularity grow.

XHTML and template.php

Since I use inline SVG in all of my sites, I need to serve my pages up as XHTML. I couldn’t find a Drupal module or option that triggers Drupal to serve the pages up as XHTML, so I added the following code at the very top of the page.tpl.php page:

<?php
header("Vary: Accept");
if (stristr($_SERVER["HTTP_ACCEPT"], "application/xhtml+xml"))
    header("Content-Type: application/xhtml+xml; charset=utf-8");
else
    header("Content-Type: text/html; charset=utf-8");
?>

All this code does is check whether the user agent can support XHTML. If it can, the page is served up as XHTML; otherwise HTML. Using embedded PHP in page.tpl.php for the theme works as desired. However, the content type of the page no longer agrees with the content-type meta element, which is included within the $head variable.

  <head>
    <title><?php print $head_title ?></title>
    <?php print $head ?>
    <?php print $styles ?>
    <?php print $scripts ?>
    <!--[if lt IE 7]>
      <?php print phptemplate_get_ie_styles(); ?>
    <![endif]-->
  </head>

One solution would be to not print out the $head variable and just hard code all of the head entries. However, when you add a new module, such as the RDF module, which adds entries to the $head variable, you either have to hard code these in, also, or you lose functionality.

Instead, I used the template.php file, which is used to override default Drupal behavior. Specifically, I created a variant of _preprocess_page for my subtheme, used this to access $head, and alter it.

function flame_preprocess_page(&$vars) {
  $head = $vars['head'];
  $head = str_replace("<meta http-equiv=\"Content-Type\" content=\"text/html; charset=utf-8\" />",
              "<meta http-equiv=\"Content-Type\" content=\"application/xhtml+xml; charset=UTF-8\" />", $head);

  $head = str_replace("<link rel=\"alternate\" type=\"application/rss+xml\" title=\"Burningbird's RealTech RSS\" href=\"http://realtech.burningbird.net/rss.xml\" />\n","",$head);

  $vars['head'] = $head;
}

I am still getting my head around customization in Drupal, and will have a follow-up posting later, after I’ve had more time to work through issues. In the meantime, from my understanding, the _preprocess_page passes in an array of system variables, each of which can be accessed and altered, as I’ve done in the code example. The subtheme naming is essential, otherwise I would overwrite the use of the function within the Garland theme.

There is another theme specific function for overriding variables called _phptemplate_variables, but I gather that was Drupal 5 and the approach I used is Drupal 6.x and forward.

Now, the head entries are as I want them, and modules such as RDF can add their entries without me impacting on their work. More importantly, with the addition of the XHTML support, I can add inline SVG and the SVG will display correctly for those browsers that support inline SVG.

(Note this image is now included using the IMG element. I’m now using WordPress, and WordPress does not allow inline SVG.)

hello world in svg

SVG and Dashed Lines

I’ve moved on from SVG to the Canvas element, and am still suffering whiplash at the downward steepness of the step. Leaving aside that one can defeat canvas easily just by turning off script, about the best documentation I found on the element is Mozilla’s implementation. The specification is buried within the HTML5 work, which if you think on it, defeats every last bit of argument about not including SVG because it’s “presentational”.

About the only negative associated with SVG is how to include it in the pages–the specification, itself, is really nice. Once all of the features are supported in the main browsers, you’re going to see some amazing stuff.

You don’t realize how nice SVG is, until you look at the Canvas element. For instance, I created an SVG example on how quadratic bèzier curves work in SVG. The canvas element also supports the same type of curves, so I went to re-create the example. I hit a wall immediately. Why? Two words:

“dashed lines”

No, there is no way of adding either dashes or dots or combination to lines in canvas. You can use a custom function and create tiny little lines using lineTo and/or one of the curve functions, but there’s no way to actually just specify the dash-dot pattern to use, and forget about it. My canvas demonstration of quadratic bèzier curves ended up looking a tad bit different.

I went searching on HTML5, the canvas element, and dashed line support and found a couple of discussions about supporting dashed lines in canvas. The official word is: not trivial to implement, no one really wants them.

Considering that one of the first implementations on the canvas element I created uses dashed lines, I beg to differ on the ‘no one really wants’ assumption. Sure, I can use a custom function, such as the one I’m using to emulate a rounded corner rectangle, but I can’t help thinking this isn’t the most efficient approach. The user agent should be able to optimize for dashes in line drawing if these are part of the specification, but there is no real optimization for functions that create hundreds of little dashes based on rotate, curve, line, move.

While researching the missing ‘dashes’, I ended up being more caught up in the discussions associated with the canvas element. It wasn’t until looking for dashed line that it hit me: why was there such deeply presentational discussions associated with a version of HTML that’s specific to semantics, only? Especially when you consider that in the recent discussions about support for SVG in HTML5 there was pushback for supporting SVG within HTML5 because SVG is ‘presentational’. In fact, Jacques just wrote, the following on this topic:

The subject came up in a discussion over at Sam’s blog about SVG-in-HTML5. Some people were arguing that, even if it were technically possible, it would be undesirable to sully HTML5 with the inclusion of foreign dialects, like MathML or SVG. The latter, in particular, was in some quarters considered too “presentational.”

This annoyed me sufficiently that I gave the following example:

Say I wish to discuss irreducible representations of SU(3). I think it should be perfectly acceptable to point out that: Rank-2 Symmetric Tensor Representation⊗Fundamental Representation=Adjoint Representation⊕Rank-3 Symmetric Tensor Representation

No, I don’t understand what Jacques wrote, either, but the SVG shows properly.

Of course, the issues associated with SVG (and MathML and RDF/XML, if it comes to that) go beyond just the presentation. SVG is a well-defined markup based on XML, which requires precise handling on the part of the user agent and the agent generating or creating the SVG. HTML5, on the other hand, is meant to be a less rigorous environment, where the lack of precise application of markup is handled with greater indulgence.

Lack of precise application of semantic markup, I should say, as there are new semantic attributes, values, and elements being added to the spec. One assumes this is so that search engines, such as Google, can better process the web page ‘semantics’. In fact, much of the semantics associated with HTML5 seems to be specific to search engine optimization.

I can understand some of the ‘foreign markup’ implementation concerns about SVG. What I can’t understand is why the HTML5 group hasn’t split the canvas element off into a separate specification–not if presentational purity is a goal of the specification. Just because it’s easier to include the canvas element in HTML5, doesn’t mean it should be included, if the underlying purpose of HTML5 is to provide an interim, better behaved, but more forgiving, semantic web page markup. According to the HTML5 spec:

This specification is limited to providing a semantic-level markup language and associated semantic-level scripting APIs for authoring accessible pages on the Web ranging from static documents to dynamic applications.

The scope of this specification does not include addressing presentation concerns (although default rendering rules for Web browsers are included at the end of this specification).

The scope of this specification does not include documenting every HTML or DOM feature supported by Web browsers. Browsers support many features that are considered to be very bad for accessibility or that are otherwise inappropriate. For example, the blink element is clearly presentational and authors wishing to cause text to blink should instead use CSS.

Blink is presentational, while dashed lines are not? I suppose one could also push line patterns off on CSS, but then why would one not also push stroke style and fill pattern, as well as such esoteric items as maximum miter height?