Some remarks on XBL, BECSS and related

1. As for the discussion whether CSS by itself is safe: it is. As it has been mentioned (mid:88246641044.20031030122310@iname.com and mid:BBC63E2A.2F4DA%tantek@cs.stanford.edu (hey, what does that % escape in the second URI?)), disabling scripts prevents also those contained in content property values with procedural URIs. I imagine the same would be true with scripts in linked XBL documents (their functionality would be, of course, limited, but not nullified).

2. XBL seems to be much more general than it is realised. It has got the potential of applying any stylesheet whatsoever. The only dependence on CSS is on the other side: linking from the document. It would be more modular (in the spirit of W3C specs) to say nothing about that in the XBL spec and have the BECSS module define only the binding property. Then it would be possible to apply XBL behaviours using other styling mechanisms, provided they define such possibilities. I see this much preferable because tightly coupling XML and CSS isn't a good idea. Their syntax is different, which in fact reflects the very different applications. Unstyled XML is often useful (especially in non-presentational contexts), and I could easily imagine CSS (with Selectors module properly replaced) for syntax highlighting, indentation and selective unfolding which modern IDEs offer. Should there be a separate MIME type for CSS rulesets (with specific rules adressable by URI fragments)? Should a!
  ruleset pertaining to one element only (with selectors in particular rules varying over pseudoelements and pseudoclasses (possibly attribute selectors and so on)) be granted a distinguished status? A use case could be the syntax of style attribute (no progress on that for a long time).

3. Shouldn't that be rather two properties: binding-definitons (of type URI) and binding-mime (and possibly binding as shorthand)? Should MIME types be a primitive type in CSS? Or rather <URI, MIME type> pairs? The current practice is no. How does the user agent obtain it for resources referenced with URI-typed properties? If the scheme is http, then it gets it in the Content-Type header, but such assumption cannot be made for example for the file scheme (and even if the relevant RFC required it, the passing mechanism would be system dependent).

4. Backgrounds should be backgrounds. No interactivity, no focus, no movement (well, maybe, but I feel this would fall under synchronized multimedia, as the foreground document may have got its own timeline). The CSS 2.1 spec says:
> User agents may vary in how they handle invalid URIs or URIs that designate unavailable or inapplicable resources.
In my opinion applicability as a background requires being possible to render some static (renderable in all visual media, the most representative one being probably print) representation. In HTML (if the user agent chooses to support it for backgrounds) this would probably mean performing all the actions normally until the load event handler terminates. The only mandatory top-level media type to support should be image (and text?).

5 (of general interest to people defining formats that need MIME types). Even for interactive and timed resources using image top-level media type there is some suitable static representation (SVG - similarly as HTML?, animated GIF - the first image in the sequence? (this one should be video/gif anyway to distinguish)). Is this true fo text? What about text/html? It seems unclear to me (having read all the rationale, which wasn't exhaustive) why for XHTML the type application/xhtml+xml has been chosen and not text/xhtml+xml even though the image top-level media type is assigned to such applicational and in many ways dynamic things as SVG. I think a generic plain text renderer is at least equally well suited for XHTML 1.1 (and even better for XHTML 2.0 as it, after ages of putting everything into HTML, finally concentrates more on hypertext and less on specific extensions which should be addressed by their own specs (nevertheless, the things like XHTML+SMIL+MathML+... should !
 use application top-level media type)) as a printer is for interaction and animation rich SVG.

6. Ian Hickson wrote:
>> It wasn't clear after a quick read.  For example, I read this "A binding
>> attached through CSS cannot be removed using removeBinding.", but wonder
>> what would happen if I used deleteRule.  I'm assuming that it would
>> remove the binding, and fire any binding related events, but it is
>> unclear how the interaction with DOM 2 CSS works from the spec.
>
> The spec shouldn't need to define that. deleteRule() works the same way as
> removing the style rule any other way (e.g. it no longer matching the
> document).
You're right. But keep in mind that this question was raised. This shows that such things aren't obvious at first glance even to geeks. Where does the user (of a spec, in a wide sense: implementor, author...) find the answer? It is crucial that they find one easily because these are often things of the sort that most impacts interoperability. The informative sections are for this. I feel the HTML 4.01 spec did a much better job in this aspect than many specs produced nowadays, providing much high quality background and explanatory material.

7 (media for embedding content - of general interest). What (CSS) media type does apply to the content inserted by the content property (or HTML object element as well)? How to apply width to an audio resource? IE would render graphically the interface of an ActiveX control handling the audio, but is that correct? I think it isn't, and could be imposed by inserting the ActiveX object explicitly and providing the audio resource URI as a parameter (note also that this is currently the only standards compliant workaround for the most popular Java plug-in). Still, at present the media type of replaced content isn't known (unless inferred from MIME type, if one is provided) until fetching. And nothing is said what the user agent is supposed to do when that type is different from the document's one. It could also be that the linked content has no madia type at all, for example it is an object implementing some procedures for use with scripts, not intended for any rendering.

8. Where do various objects live? This question should be posed rather on www-component-extension@w3.org but the state of that one is miserable. I mean element ids, (X)frame names, CSS counters, script variables and procedures (unified in ECMAScript)... For example IE (the only browser I know to support more than one scripting language) automatically puts them all (didn't check the counters) in one namespace, thus allowing JScript and Visual Basic Script to call each other and to refer to elements simply by their ids (OK, that's gone too far). Should the style languages specs say something on that? Maybe CSS DOM method to access counters - albeit changing their values would be useful in scripts executed during document loading (a dirty feature, like document.write), notwithstanding potential difficulties for elements and style rules inserted dynamically afterwards (which even now I think requires recalculating counters).

9. Should xml:id be accompanied by xml:class (not only for styling purposes)?

10 (question to anyone). What happened to the Document Fragment Interchange draft announced a few years ago, which isn't now found by the Google search of the site?

Best regards,
Chris Maczyński

Received on Thursday, 15 April 2004 04:14:54 UTC