I would like to follow up on the points regarding the correct patterns for degraded markup for each widget so that we can come up with a set of recommendations which can go in the Dojo docs.

Excellent, I’d love to help. Email’s on it’s way.

Progress on the DTD front isn’t likely before Dojo 1.0, but may be possible afterward.

I understand that this isn’t the most pressing thing for you all right now, but I am glad you’re interested in it as an option. I’m happy to help in this regard as well, just let me know.

As for CSS rules being used to locate widgets, not very likely as the default why is the class selector more blessed than attribute selectors?) but perhaps pluggable. There are only a couple of things that would need to change for such a plugin to work in Dojo.

It’s not a hard gap to fill, for sure. I guess I am of the mindset that CLASSes are for classification of elements (not just application of CSS). That’s why I favor it as a means of including additional info about an element or using it as a hook for a script. We can talk more about this at length as well via email.

I agree (as we discussed F2F) with much of what you’ve said. I can’t seem to find your email anywhere, but I would like to follow up on the points regarding the correct patterns for degraded markup for each widget so that we can come up with a set of recommendations which can go in the Dojo docs. I’d appreciate it if you’d send me private mail at alex at dojotoolkit dot org.

Progress on the DTD front isn’t likely before Dojo 1.0, but may be possible afterward. As for CSS rules being used to locate widgets, not verey likely as the default (why is the class selector more blessed than attribute selectors?) but perhaps pluggable. There are only a couple of things that would need to change for such a plugin to work in Dojo.

Regards

The vendor-specific prefix is present on these properties because the CSS 3 specification is still in draft.

Right. I know that’s the intent, but the problem is that these features have been publicized and are now being incorporated into stylesheets as though they were part of the spec. I see that as somewhat of an issue. The spec itself states that

Authors should avoid vendor-specific extensions

But, unfortunately, few authors ever do.

I guess what I am proposing is that the term “vendor” be opened up to more than just the browser software makers. I would like to see developers push more presentational configuration into CSS than currently exists. For example, we should be able to extend the language to do fill gaps (provided we document it, obviously), not just “preview” what’s coming in some future version of of the language. Here’s one possibility:

.dojo-form-horizontalSlider {
  -dojo-show-buttons: false;
  -dojo-intermediate-changes: true;
}

Both of these properties are presentational about the rendering of the slider widget. Obviously you could get more specific about instances, but I think it makes a valid point. After all, the spec does not say this is only for previewing features. It says that if a vendor needs to add a property, it can. My feeling is that we should use that opportunity.

Plus, -moz-border-radius and -webkit-border-radius (as fun as they are to play with) feel like a cop-out to me. Other features of CSS3 are being implemented by both Mozilla and Webkit without the vendor extension (overflow-x and overflow-y, for instance). Why pick and choose?

Chances are, you’ve come across this when implementing -moz-border-radius or -webkit-border-radius (which, honestly, both seem superfluous to me when the CSS3 spec includes border-radius as an actual property…why not just support that?).

The vendor-specific prefix is present on these properties because the CSS 3 specification is still in draft. This means that a given vendor’s implementation of the property that was implemented against the specification on a given date may not be completely compliant to the specification when it leaves draft status. It’s a way of letting developers experiment with the new CSS 3 features while still reminding them that they are a work in progress and are subject to change as specification matures.