Category: Technology

Categories
Technology Web

Apple meet orange

Speaking of email, how absolutely idiotic to pronounce the death of email because today’s teens aren’t using their email accounts.

Today’s teens are also wearing their pants around their ankles–does this mean, then, that civilization will eventually lose its waist? I’m sorry, dear people, but frankly I’d rather not see most of your underwear clad butts.

We seem to be desperate to be the first to ‘spot trends’ that we take an audience that is known to have certain behavioral characteristics, and extrapolate what this means into the future. This is silly, as history shows us that teen behavior does not a forecast for the future make.

For instance, from my own youth, extrapolating our behavior into the future, one would assume the phone would be dead by now, because we spent all of our time in each other’s ‘pads’: smoking weed, dropping acid, and painting flowers on our bell bottoms, as we contemplated revolution and free love with equal passion. The phone was The Man.

From what I can see of drivers wherever I go, not only is the telephone not dead, it’s used more now than at any time in the past.

Focusing on what teens want has already ruined television. You can’t watch a show now without some blurb showing up obscuring half the screen with instructions about how the person watching can make the experience more ‘interactive’. Why add these to shows? Because marketing has deemed that today’s youth insist on such a barrage of noise in order to grasp and hold their attention.

Now, we’re ready to hold requiem on email, and other longer, thoughtful communications, because kids have the attention span of gnats. Welcome to the brave new world. Oh, excuse me: BRV NW WRLD. LOL.

update

An anonymous response in another weblog to the “email is for old people” pronouncement:

To be fair, what is a more efficient method for communicating “I AM WATCHING TELEVISION” or “I JUST TOOK A POOP AND IT STANK UP THE BATHROOM” than through something like twitter? It’s too frivolous for an email.

But likewise, am I going to communicate an action plan or discuss something with a customer via AIM or twitter or myspace? Fuck no. IM is for instant communication. Twitter is for pointless, self-involved drivel. Myspace is for idiots who want to consoladate their entire internet experience into a single website (and a single point of failure) just like the good old BBS days, before they were born —- and email is for people who need to convey important information, delicate information, detailed information or otherwise engage in an actual conversation.

I use IM constantly in my line of work. I’m a developer and our entire company of 45,000 people globally requires that everyone use our own developed commercial messenger (uses XMPP, much like jabber and is for all intents and purposes — jabber). Most of my colleagues are not even within driving distance. And even if they were, a lot of us telecommute full time. So IM is absolutely a necessity.

But for every IM message, there are a few dozen email messages. Whether it’s discussions on an internal list or another. Whether it’s communicating with customers or field engineers or team discussions and management discussions to touch base or regarding staffing or action plans.

So yes, young people may just use twitter, IM and myspace today . . . but if they plan to ever have discussions that go beyond what color their crap was and what they’re doing at that very instant (OH MY GOD, WE’RE ALL EAGERLY AWAITING YOUR NEXT TWITTER!) and beyond self-involved attention-whoring on myspace or trying to get off with some loser on instant messaging, they’ll eventually find themselves forced to gravitate toward email. And if they don’t – they’ll be shark food for the rest of us in the workforce.

Categories
JavaScript

We can’t afford another browser war

Recovered from the Wayback Machine.

It was with a sense of foreboding that I read the posts that swam past on Planet Intertwingly today. First came Mozilla’s Brendan Eich’s chastisement of Microsoft’s Chris Wilson, followed in a short while by commentary by Sam Ruby, where he wrote:

It is interesting how the don’t-break-the-web meme means different things to different organizations: Mozilla, Microsoft.

I’m not a language designer. My only stipulation with a new scripting language is that whatever constructs are added to ECMAScript4 need to be backward compatible. We can’t afford to re-write a couple of billion web pages because the ECMAScript group got clever. From what I’ve read in the past and in these new writings, Eich concurs, as does several other members of the team.

In regards to the new items added to the language: I share other concerns that ECMAScript–no let’s call it JavaScript because that’s how it’s known in the world–may become bloated and over large. I can understand about making it into a ‘real’ language, but I’m less concerned with posterity than I am getting a job done, quickly and efficiently. In other words: I don’t have any ego involved with the fact that I work with a programming language many folks consider somehow less worthy. If the extensions make a better language enabling me to do a better job, that’s great. Otherwise, leave the esoteric for ACM papers.

The future perfect ECMAScript is currently not my concern. My concern on this interchange between Mozilla’s Eich and Microsoft’s Wilson is that we’re seeing the seeds being planted for another round of browser wars, similar to what we had a decade ago. However, today’s web isn’t like the web of a decade ago, because today’s web pages are much too complex to attempt to cover every nuance and difference in implementation with if statements and conditional tests. It was especially disquieting to read comments to the effect that, it’s OK if the companies don’t agree: we can use Flash. Flash is not an alternative to open standards. We don’t need any more Flash dependency as a way of ‘soothing over’ corporate intransigence. Neither do we need more SVG plug-ins, or Google cross-browser libraries. Workarounds are no longer acceptable.

Any company is going to want to implement a version of any specification that favors what they currently have, as much as possible. Of course, this is understandable. Accept the fact that this is understandable. What keeps this behavior in line is there is enough push from other forces that everyone eventually has to compromise, and no one is a clear winner. When no organization is a clear winner, this typically means that everyone, eventually, ends up being a winner.

There’s no denying that Internet Explorer continues to be a problem. I found it unacceptable that Microsoft would put in time to create its own 2D graphics system with Silverlight, when one already exists with both SVG and Canvas (the Canvas object, not markup element). There was absolutely no good reason for this, and no amount of plushy blue monster or outreach effort is going to hide the fact that Microsoft basically did it’s own selfish thing with Silverlight.

There is no denying, however, that Microsoft’s browser continues to dominate (though every year, it dominates less). There is also no denying that Eich has considerable ego invested in ECMAScript–to the point where I have to wonder if this may make him overly aggressive, leading to confrontations that could injure the likelihood of pulling together a new version of JavaScript all browser makers are willing to endorse. We need a consistent platform: no matter how good the language, if a sizable number of people are using a browser that doesn’t implement it, the language is screwed, the browsers are screwed, we’re screwed.

“So I’ll expect to see no more of these lies spread by you.” No matter how angry you get, or frustrated, or peeved, if you want to work in an open standards group, particularly if you want to lead an open standards effect, you can’t write statements like this! Period. End of story. Along with the authority of leadership comes responsibility, and such statements are irresponsible. Where is Mitchell Baker? Time for her to step in and exert a calming influence. At a minimum, act as referee.

The same could be said for the Microsoft representation. No matter how subtly worded, we’re picking up our marbles and going home, neener, neener is not ‘working together as a team’; nor is it considering the true best interests of the web, in general, and of those loyal to Microsoft products, specifically.

Sam mentions that this issue is one based on culture. Frankly, from these exchanges, it seems more like a pissing contest to me.

Disappointing.

update

Could have done with a little less Scoble fandom, but a good overview of the players. I’m a little concerned about references to offline discussions.

Money quote in comments, by Douglas Crockford: “Simplicity is underrated.” Amen.

Categories
JavaScript Technology

We can’t afford another browser war

It was with a sense of foreboding that I read the posts that swam past on Planet Intertwingly today. First came Mozilla’s Brendan Eich’s chastisement of Microsoft’s Chris Wilson, followed in a short while by commentary by Sam Ruby, where he wrote:

It is interesting how the don’t-break-the-web meme means different things to different organizations: Mozilla, Microsoft.

I’m not a language designer. My only stipulation with a new scripting language is that whatever constructs are added to ECMAScript4 need to be backward compatible. We can’t afford to re-write a couple of billion web pages because the ECMAScript group got clever. From what I’ve read in the past and in these new writings, Eich concurs, as do several other members of the team.

In regards to the new items added to the language: I share other concerns that ECMAScript–no let’s call it JavaScript because that’s how it’s known in the world–may become bloated and over large. I can understand about making it into a ‘real’ language, but I’m less concerned with posterity than I am getting a job done, quickly and efficiently. In other words: I don’t have any ego involved with the fact that I work with a programming language many folks consider somehow less worthy. If the extensions make a better language enabling me to do a better job, that’s great. Otherwise, leave the esoteric for ACM papers.

The future perfect ECMAScript is currently not my concern. My concern on this interchange between Mozilla’s Eich and Microsoft’s Wilson is that we’re seeing the seeds being planted for another round of browser wars, similar to what we had a decade ago. However, today’s web isn’t like the web of a decade ago, because today’s web pages are much too complex to attempt to cover every nuance and difference in implementation with if statements and conditional tests. It was especially disquieting to read comments to the effect that, it’s OK if the companies don’t agree: we can use Flash. Flash is not an alternative to open standards. We don’t need any more Flash dependency as a way of ‘soothing over’ corporate intransigence. Neither do we need more SVG plug-ins or Google cross-browser libraries. Workarounds are no longer acceptable.

Any company is going to want to implement a version of any specification that favors what they currently have, as much as possible. Of course, this is understandable. Accept the fact that this is understandable. What keeps this behavior in line is there is enough push from other forces that everyone eventually has to compromise, and no one is a clear winner. When no organization is a clear winner, this typically means that everyone, eventually, ends up being a winner.

There’s no denying that Internet Explorer continues to be a problem. I found it unacceptable that Microsoft would put in the time to create its own 2D graphics system with Silverlight, when one already exists with both SVG and Canvas (the Canvas object, not markup element). There was absolutely no good reason for this, and no amount of plushy blue monster or outreach effort is going to hide the fact that Microsoft basically did its own selfish thing with Silverlight.

There is no denying, however, that Microsoft’s browser continues to dominate (though every year, it dominates less). There is also no denying that Eich has considerable ego invested in ECMAScript–to the point where I have to wonder if this may make him overly aggressive, leading to confrontations that could injure the likelihood of pulling together a new version of JavaScript all browser makers are willing to endorse. We need a consistent platform: no matter how good the language, if a sizable number of people are using a browser that doesn’t implement it, the language is screwed, the browsers are screwed, we’re screwed.

“So I’ll expect to see no more of these lies spread by you.” No matter how angry you get, or frustrated, or peeved, if you want to work in an open standards group, particularly if you want to lead an open standards effect, you can’t write statements like this! Period. End of story. Along with the authority of leadership comes responsibility, and such statements are irresponsible. Where is Mitchell Baker? Time for her to step in and exert a calming influence. At a minimum, act as referee.

The same could be said for the Microsoft representation. No matter how subtly worded, we’re picking up our marbles and going home, neener, neener is not ‘working together as a team’; nor is it considering the true best interests of the web, in general, and of those loyal to Microsoft products, specifically.

Sam mentions that this issue is one based on culture. Frankly, from these exchanges, it seems more like a pissing contest to me.

Disappointing.

Categories
SVG

Flawed Safari on Leopard

It would seem that Apple released Leopard with the branch of Webkit that can’t hack certain uses of SVG. Because of this, you won’t be able to see the comments, due to the use of SVG to provide head and footer caps surrounding my comments.

This was a known problem with Webkit, and I filed a bug. I’m disappointed that Apple would release a broken version of Safari. I mean, it’s not as if the company isn’t taking a hit for it’s use of graphics in Leopard, already. At the least, it could put out software that’s working.

In the meantime, I may end up pulling my use of SVG. Or I might ask if you would please use another browser and let Apple/Safari/Webkit know that the browser’s handling of SVG is broken.

update

I found the problem, and an old unassigned bug related to this at WebKit.

What’s happening is that the SVG is expanding to fill the entire containing DIV element within which the SVG is placed (when display is set to ‘block’, not ‘inline’), either wiping out or ‘hiding’ the other contents. I surrounded the SVG in the comments and sidebar within a containing DIV element, and the SVG is no longer ‘overlaying’ (or removing) the rest of the content.

Question is, where is the bug here? Me for not embedding the SVG element in it’s own DIV element? Or WebKit for wiping the other content out on the parent element?

Regardless, the SVG is now working for Safari on Leopard.

Categories
SVG

Dash it all

‘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?