Categories
HTML5

Extensibility and markup, again and again

Recovered from the Wayback Machine.

Proving that the issues with extensibility will never go away until faced, and resolved:

  • Anne van Kesteren: Concerns that HTML5 does not have distributed extensibility. That is, namespaces. What people seem to want is to extend the browser with hundreds of markup languages. (How this keeps things simple to answer was not something I saw addressed.) You need something else than namespaces for that though, to start with. Also, what is wrong with using XML for this?
  • Sam Ruby: It seems that the distributed extensibility discussion won’t go away like apparently some would hope it would […] It occurs to me that Anne may be intentionally being thick here. what is wrong with using XML for this? Come on. I can answer that with two words: IE, and Postel. Next question?
  • Dave Orchard: While I agree with Sam’s assertion that misdirection is going on and IE8 is crucial, I think the real issue is that the anti-distributed extensibility crowd want control over all the languages that could be added into HTML. There’s no changing XML that would make them happy. I think the goal is that the HTML WG becomes the gatekeeper over any new languages that get added into the browser. We’ve seen it with aria-, SVG, MathML. Note that IE8 has a form of namespaces, and Chris Wilson was a supporter of distributed extensibility on the HTML WG list.

I’m not sure we need another form of namespaces. What we need is to address the concept of extensibility, without looking at the mechanics. Is extensibility good? Years ago, I would have been puzzled at even asking this question. Of course extensibility is good. Now I’m not sure that this opinion is shared by one and all. So, perhaps we should ask, Is extensibility bad? From the answers, we might find out where the problems exist, and maybe generate a dialog that results in solutions.

Categories
Browsers HTML5

OMG! Web Developer has to wait! The Horror!

Where I focused on Ian Hickson’s statement about extensibility, every other person, and their brothers, sisters, and aunts are throwing a hissy because of the HTML5 timeline.

Scott Gilbertson writes:

Even if your 2022 ronc-o-matic web-enabled toaster (It slices! It dices! It browses! It arouses!) does ship with Firefox v22.3, will HTML still be the dominant language of web? Given that no one can really answer that question, does it make sense to propose a standard so far in the future?

Jeff Croft writes:

I’m not saying the specs should go away. They absolute serve a purpose. I’m just saying that I personally am done paying much attention to them. Instead, I’m reading blogs like Surfin’ Safari and Mozilla Developer News to find out what the new shiny is in browsers, because these are the things I can actually take advantage of in serving my clients and users.

 

And?

So?

Specification work was never focused on the end users, it’s focused at the user agents or others who have to implement the specifications. The Mozillas, Apples, Operas, Microsoft, et al. The only reason I pay attention to any of it is because of my concern about extensibility.

In the meantime, the new stuff that is HTML5 is leaking into browsers now, not years from now. That’s part of the specification process—actual implementation on the street in order to “proof the spec”, as it were. And pieces of HTML5 are not just showing up in Firefox, Opera, and Safari/WebKit— IE8 has a few HTML5 tricks up its sleeve.

Heck, HTML5 isn’t the only longish spec under development. CSS 2 started in 1998, the lost call for CSS 2.1 was in 2002, the candidate recommendation was in 2007, and Microsoft is only now providing CSS 2.1 support. That’s ten years, end to end.

In the meantime, I’m using CSS3 stuff that’s only supported by a couple of browsers, and the final release of all the CSS3 bits is probably years out, too. Of course, I only play around with my own spaces—professional web designers and developers know that we can’t necessarily use the shiny new stuff for client applications, because we’re still having to support browsers that are seven years old.

Hey! We’re still supporting browsers almost as old as the timeline when HTML5 will be finalized! I guess things aren’t as “today” and “now” as we think they are.

The point is, specifications take time, or at least, good specifications typically take time. Any doofus can toss a quick spec out and call it done, but who wants to use the doofus spec?

That schedule part of what Ian had to say didn’t phase me. As far as I’m concerned, the group can take as long as it needs. In the meantime, I’ll play around with the local storage, and some of the other odds and ends, as I keep putting in my annoying “But what about SVG?” “But what about RDF?” oar; probably helping to slow the development of the spec, even more.

Categories
HTML5

Death to extensibility

In an interview at Tech Republic, HTML5 Editor Ian Hickson stated:

The second big controversy in recent history was over extensibility. There have been some requests to allow people to extend HTML without speaking to the committees working on HTML. We’ve provided a number of mechanisms for this (the class and rel attributes, the data-* attributes, the meta element for page-wide metadata, the script element for non-script data blobs, the embed element for plugins), but some people simply want the ability to invent their own elements and tag names. So far, we’ve managed to avoid that, and we’ll have to see if we can continue.

Yes, but we’ve still not resolved—at least, I’m not aware of any resolution—about how to incorporate MathML, RDFa, and SVG into HTML5. I can’t help thinking we’ve spent more time trying to prohibit extensibility than we would if we just provided the mechanism.

In addition, I’m frankly confused about how we’ll pull off a consistent model between HTML5, which is rigidly inflexible, and XHTML5, which is anything but. If what’s incorporated into HTML5 differs from what’s allowed in XHTML5, do we just…wing it?

The whole point of XML years ago was because of issues like this—how do we create a markup that can be extended without having to update the underlying specification/model with each new addition. Ever since, we’ve been running in horror from the Yellow Screen of Death—the negative aspect of XML we fixate on—while arguing, endlessly, about extensibility—the most beneficial aspect of XML. I can’t help thinking that we should keep the extensibility and just get rid of the Yellow Screen of Death.

However, I’m not expert in these things. I am just a humble web developer, with simple needs. One such need is I don’t want to lose what I have now.

Categories
HTML5 Semantics

Separating presentation from semantics

After all these years, we have finally reached the point where we’ve separated page organization from presentation, and now we’re about to embark on the same mistakes again, but this time with presentation and semantics.

I’ve been following the issues associated with the vocabindex Drupal module, including one where the person submitting the bug stated the vocabindex use of UL was incorrect. We’re supposed to, MXT writes, use definition lists rather than unordered lists for any lists of terms with associated definition.

At first glance, it does seem as if the vocabindex module is using the unordered list incorrectly. After all, look at any of my category pages (such as the one for the Semantic Web)—what you see is a list of “terms” and their associated definitions. An obvious candidate for definitions lists.

Look more closely, though. In my sidebar menu I list the vocabindex terms as links to web page URIs, but there is no definition attached to any item. The description, if one is given, is, instead, added as a title attribute to the item and displayed only when the item has cursor focus. Yet, it’s the same data. Does this mean, then, I’m somehow not properly displaying my menu items? Should I have a huge sidebar, with the item description given underneath?

More importantly, whether I have a given text description for each item is purely optional, some do, some don’t. Yet the items in the list have meaning without any associated description. In fact, each item in the list is really nothing more than a label for a bucket to hold content. I could just as easily use foobarsillyputty as labels, except that I’m trying to use “meaningful” labels in order to enable you all to better find past content.

In the absolutely ancient W3C page where lists are covered a list of ingredients is given as an example of an unordered list:

  • 1 cup sugar
  • 1 cup oil
  • 2 cups flour

However, I don’t see that anyone would have a problem with adding parenthetical information to this list in order to further clarify the items:

  • 1 cup sugar (light brown granulated by C & H)
  • 1 cup oil (canola or corn, but not olive)
  • 2 cups flour (white or mixed white and whole wheat)

This is really nothing more than what the vocabindex is doing with the vocabulary index terms within both the index pages and my sidebar menu: a listing of items and a (parenthetical) description to clarify what that item is. However, it’s only when the description is displayed as a “tooltip” that one sees the item as a clarification phrase, only. When presented in the index pages, it “looks” like a definition list, and so we want to have it marked up this way— mixing up semantics and presentation.

A definition list is assumed to have two pieces of information; the term or phrase and an associated definition. Even when not present, the definition is still assumed to be forthcoming at some point— not having it is the exception, not the rule. An unordered list is just that: a list of items. They can be a list of items to buy at the store, select from in a form, or click on in a web page. There’s no assumption that any additional information is necessary for the item. If there was, Drupal would make this information mandatory rather than optional. The application and associated developers would definitely discourage the use of the items in a tag cloud or other format where only the term is given because the term, by itself, would be meaningless.

Yet we look at how the terms are portrayed in a page like the vocabindex page I linked above, and that’s enough for us to say we should use one form of markup over another because it’s more “semantical”. Further exploration online at other sites who attempt to define the differences between unordered lists and definition lists shows the same thing: if we see two pieces of data, we’re assuming a definition list, because that’s what it looks like—not what it is.

The HTML5 document adds another key element to the discussion of definition lists by stating that definition lists are name-value pairs. From this can we deduce, then, that the name has no meaning without the value. That’s my interpretation: that a definition list is the proper semantic markup only when data is defined within a context of names and associated values, both of which are meaningless without the other. If, however, *HTML5 allows us to list the names without values, or the values without the names, then the HTML5 document is imprecise, and we should just use whatever we want to use— semantics can not be derived from imprecision.

Currently, in Drupal, vocabulary terms are discrete labels, nothing more. Any description is for clarification not definition, and isn’t essential to the meaning of the term. Forget how the vocabindex pages “look”, and focus on what the data means. If we can’t do that, then this whole semantic markup thing is a bit of a farce, really.

*Confirmed: it doesn’t

Categories
Specs

The nobility of specification work

Hank Williams responded to the recent ECMAScript Harmony announcement with a post titled, Ru Roh! Adobe Screwed By EcmaScript Standards Agreement. In it, he writes:

Adobe provided support to the standards body in helping to define the standard, and most importantly, in creating an open source virtual machine called Tamarin that would run EcmaScript 4.0. But they did all of this before the standard was officially sanctioned. EcmaScipt 4.0 was nothing more than a draft proposal. But Adobe needed to make this bet because they needed a better language than the early ActionScript was, and the existing template, JavaScript, hadn’t moved substantively forward in years.

And so Adobe released Tamarin, the EcmaScript 4.0/ActionScript 3.0 running virtual machine, and a raft of products based it…Unfortunately, while the technology of EcmaScript 4.0/ActionScript 3.0/Tamarin is compelling, the politics sucked.

Adobe and Microsoft are bitter rivals, and the last thing Microsoft would be willing to accept is wide-spread adoption of a language that is strategically critical to a competitor…And so this meant EcmaScript 4.0 was stillborn.

At the end of his writing, Hank summarizes Adobe’s plight, now that it has been betrayed:

the interesting question is what will Adobe do now. The technology they have is no less impressive today than it was a few days ago. But they are now totally on their own, which wasn’t exactly the plan.

Poor, poor Adobe. Lost in the wilds of the web, all alone.

Balderdash.

Hank is correct with his assessment of the politics and rivalry, (though not all decisions were political in nature). But he’s incorrect about his assumption that ECMAScript 4 is dead. Certain pieces of pre-existing ECMAScript 4 effort are not being pursued, true, but there will be an ECMAScript 4, they same as there will be a 5, 6, and on and on, as browsers and other applications that support ECMAScript evolve over time.

That’s really been the issue all along: there’s a group within the ECMAScript community that has been pushing a much more aggressive course in the development of the next specification release than other players have been comfortable with. By other players, I don’t mean only Microsoft— Google, Yahoo, Opera, Apple…all of the companies impacted by ECMAScript have agreed, with relief, that an interim specification release with full browser company support is the wisest course, with more cautious development in the future.

In addition, Hank also overplayed the nobleness of Adobe’s contribution of Tamarin, as well as the company being “screwed” in this decision. For one, Adobe agrees with the Harmony effort, while managing to get its digs in about the superiority of its offering, as implemented in Flex et al.

Make no mistake: Adobe knew it was throwing the cat among the pigeons when it contributed Tamarin. In 2006, I expressed my concerns about Tamarin:

So what do I think of all of this? I think it’s exciting, I love the canvas element and I’m interested in many of these other innovations, it’s good to revisit HTML, but I wouldn’t be me if I also didn’t note concerns: HTML element bloat; confusion as to direction of standards and where people should be heading; vastly incompatible web pages as browsers desperately try to keep up with all the changes; frustrated web page developers and designers also trying to keep up with changes; and a growing dominance of Mozilla/Adobe in regards to JavaScript and whether this could lead to a non-neutral ECMAScript 4.x, which does no one any good.

In a way, Hank’s biggest misunderstanding is his assuming that any of the other organizations involved with ECMAScript are somehow more “noble” than Microsoft in their involvement. Frankly, that’s a naive assumption. The best we can interpret all of the organizations’ involvement in the development of the ECMAScript specification—any specification, really— as being based on enlightened self interest. I wouldn’t trust any organization that says otherwise.

No, Adobe took a gamble, and the gamble didn’t pay off. It will now shrug its shoulders, reflect on the ubiquity of Flash, and continue its merry course. Forgive me if I don’t greet its noble stoicism at being stood up at the prom, with tears in my eyes and murmurs of “poor baby”.


Interesting comment in the Adobe post in answer to another comment:

Unfortunately, standards aren’t also the smartest things. Dumbing down is often a fact of standardization. We haven’t let that stop us from innovation in the past; we won’t in the future.

Yes, trying to establish a standard that is implemented in all the major browsers is really a dumb thing to do. What we should be doing is picking a winner in this little contest, and then celebrate by increasing the number of torturous cross-browser hacks for the next two decades. That’s the ticket: let’s show everyone how really smart we all are by continuing our worst practices. As long as we call it “innovation” why, it’s all right.

Yes, it’s all right.