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.

I believe that the default encoding over HTTP for text, other than
HTML, is ISO 8859/1.  The ASCII assumption is for email (or rather in
the absence of the overriding default in HTTP.)

HTML, according to its original design principles is a text/* type,
as the markup should augment the text, not completely obscure it, when
viewed as plain text.  This is also true of a lot of HTML produced by
academics using simple tools.  HTML as used in typical commercial web
pages, would be better described as application/*.  (One of the aims
of CSS, of course, is to clean up the markup so that HTML can, again,
be read as plain text, as a last resort.)

I'd agree that CSS and EcmaScript should be treated as application/*.

> 
> 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.

ASCII NUL is a paper tape runout character.  It should be completely
ignored for rendering purposes in conforming ASCII text.  Using it a
a string terminator is a programming convenience, adopted by Unix, etc.,
although other systems use other conventions, e.g. byte counts in 
Visual Basic, PL/I and Perl, etc., and control-Z (another abuse - it is
a substitute for bad parity, etc., characters) in MS-DOS.  ETX, or RS
would be more appropriate in true ASCII.

Received on Friday, 16 April 2004 02:45:36 UTC