Re: Some remarks on XBL, BECSS and related

On Thursday, April 15, 2004, 1:07:32 AM, Krzysztof wrote:


KM> 4. Backgrounds should be backgrounds. No interactivity, no
KM> focus, no movement (well, maybe, but I feel this would fall under
KM> synchronized multimedia, as the foreground document may have got
KM> its own timeline).

I agree about interactivity and focus, for the reasons you cite.
Background images in, for example, SVG should not receive pointer
events or text events and thus and animation triggers, hyperlinks etc
should not fire.

As to unattended, non-interactive animations, its not clear. I can see
cases both for and against.

KM>  The CSS 2.1 spec says:
>> User agents may vary in how they handle invalid URIs or URIs
>> that designate unavailable or inapplicable resources.
KM> In my opinion applicability as a background requires being
KM> possible to render some static (renderable in all visual media,
KM> the most representative one being probably print) representation.

Its entirely possible to use different resources as the background for
different media, and indeed having a lighter image with dark text for
print,in the case where the screen version has a dark image and light
text, could be seen as good practice.

KM> In HTML (if the user agent chooses to support it for backgrounds)
KM> this would probably mean performing all the actions normally until
KM> the load event handler terminates. The only mandatory top-level
KM> media type to support should be image (and text?).

HTML does not mandate any media types, for background or foreground
images.

KM> 5 (of general interest to people defining formats that need
KM> MIME types). Even for interactive and timed resources using image
KM> top-level media type there is some suitable static representation
KM> (SVG - similarly as HTML?,

Not sure what 'similarly as HTML' means in this context.

SVG 1.2 defines a 'snapshot time' which is a time in an animation that
is representative of the animation as a whole and can be used as a
static representation, for example as a thumbnail.

KM> animated GIF - the first image in the
KM> sequence? (this one should be video/gif anyway to distinguish)).

Yes it should have been. Note that the gif spec says that it is not
used for animations :-)

Animated PNG (MNG) is registered as video/mng fr the reasons you give.

KM> Is this true fo text? What about text/html? It seems unclear to me
KM> (having read all the rationale, which wasn't exhaustive) why for
KM> XHTML the type application/xhtml+xml has been chosen and not
KM> text/xhtml+xml

It seems very clear to me - read the definition of the text/* top
level type and clearly html does not fit it (nor does CSS). Briefly,
all content as text/* must be suitable for direct presentation to the
user as text, with an assumed encoding of us-ascii.


KM> even though the image top-level media type is assigned to such
KM> applicational and in many ways dynamic things as SVG.

Many images are dynamic. WebCGM and SVG are two examples. There can be
static and dynamic images just as there can be static and dynamic
documents.

KM> I think a generic plain text renderer is at least equally
KM> well suited for XHTML 1.1 (and even better for XHTML 2.0 as it,
KM> after ages of putting everything into HTML, finally concentrates
KM> more on hypertext and less on specific extensions which should be
KM> addressed by their own specs

Please consider how a text renderer would display an XHTML document
encoded in UTF-16. The first character would be 0, end of string
character.

KM> 7 (media for embedding content - of general interest). What
KM> (CSS) media type does apply to the content inserted by the content
KM> property (or HTML object element as well)?

The media type of the referenced resource.

KM> How to apply width to
KM> an audio resource? IE would render graphically the interface of an
KM> ActiveX control handling the audio, but is that correct? I think
KM> it isn't, and could be imposed by inserting the ActiveX object
KM> explicitly and providing the audio resource URI as a parameter
KM> (note also that this is currently the only standards compliant
KM> workaround for the most popular Java plug-in). Still, at present
KM> the media type of replaced content isn't known


It is known, when you fetch it, from the media type....

KM> (unless inferred
KM> from MIME type, if one is provided) until fetching.


This is why some specs provide a type attribute for hints, so that
there is no need to try and fetch media that are not supported.

KM> And nothing is
KM> said what the user agent is supposed to do when that type is
KM> different from the document's one.

Same as if the type had not been specified. The media type of the
fetched resource is authoritative.

KM> It could also be that the
KM> linked content has no madia type at all, for example it is an
KM> object implementing some procedures for use with scripts, not
KM> intended for any rendering.

Media type is not related to rendering.

KM> 8. Where do various objects live? This question should be
KM> posed rather on www-component-extension@w3.org but the state of
KM> that one is miserable.

I agree that not all your questions are on-topic for www-style -
related, but there might be better fora for some of the questions. The
authoritative media type one would be www-tag for example.

KM>  I mean element ids, (X)frame names, CSS
KM> counters, script variables and procedures (unified in
KM> ECMAScript)... For example IE (the only browser I know to support
KM> more than one scripting language) automatically puts them all
KM> (didn't check the counters) in one namespace, thus allowing
KM> JScript and Visual Basic Script to call each other and to refer to
KM> elements simply by their ids (OK, that's gone too far).

So you are asking about multiple scripting contexts, and sandboxes?

KM> Should the
KM> style languages specs say something on that? Maybe CSS DOM method
KM> to access counters - albeit changing their values would be useful
KM> in scripts executed during document loading (a dirty feature, like
KM> document.write),

Not *as* dirty; document.write is stream-based processing and reparsing
and thus not an object oriented approach at all and does not belong in
a dom.

A CSSOM to read a counter and, for example, insert the value of that
counter in text ("see item 5 in the list above") would be very
valuable.

KM> notwithstanding potential difficulties for
KM> elements and style rules inserted dynamically afterwards (which
KM> even now I think requires recalculating counters).

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

Possibly, but the XML Core WG is unlikely to work on it and thus, its
unlikely to be in the xml namespace.

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

This one?
http://www.w3.org/TR/2001/CR-xml-fragment-20010212.html


Its linked from http://www.w3.org/TR

XML Fragment Interchange
    12 February 2001, Paul Grosso, Daniel Veillard
    Candidate Recommendation Feedback Due 30 April 2001

-- 
 Chris Lilley                    mailto:chris@w3.org
 Chair, W3C SVG Working Group
 Member, W3C Technical Architecture Group

Received on Thursday, 15 April 2004 05:50:20 UTC