- From: David Woolley <david@djwhome.demon.co.uk>
- Date: Fri, 16 Apr 2004 07:40:16 +0100 (BST)
- To: www-style@w3.org
> > > 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