@viewport thoughts (was Re: [CSS3 UI] 'resize' property)

On 5/16/04 1:10 PM, "Sean M. Hall AKA Dante" <pianoman@reno.com> wrote:

> 
> I don't see how controlling how a window should be resized is presentational.

A window itself is presentational.

 
> In fact, this property should be revoked, as the user should be able to resize
> the window any way he/she wishes. The user will be very mad if he/she cannot
> resize the window.

Sean/Dante, as fantasai suggested, you need to read the relevant
specifications before jumping to such conclusions.

In particular, I strongly recommend you read CSS2.1 cover to cover before
continuing to make such strong statements.

 http://www.w3.org/TR/CSS21

In this case, the section on user style sheets and !important answers your
concern.


> Even if browsers start supporting this, they need an option that can overrule
> this property, even if the author has specified
> html {
> resize: none !important;
> }

Though folks used to equate <html> (or the root element) with the window,
there has been an established consensus for some time that the root element
is not the same as the window.

For paged media, there is the @page rule (see CSS2.1 and CSS3 Page Media
module) for specifying details of one or more pages that elements are flowed
into.

Similarly, there have been various @viewport proposals to specify details of
the window, e.g. if an author wanted to provide a suggestion that their
content should be displayed in a non-resizable 100px by 100px window:

@viewport {
  width: 100px; 
  height: 100px;
  overflow: hidden;
  resize: none; 
}

Several other properties could also make sense for @viewport, such as
background-*, top, left, bottom, right, padding-*.  In fact the DVB-HTML
spec has a proposal for @viewport that includes a few of these properties.

It would probably make sense to take a look at scripting functions like
window.Open() and see what other parameters are allowed, and make sure there
are CSS equivalents for @viewport.  Such a CSS construct might help some
pages minimize their use of scripting.

In addition, one could also introduce a new 'title' property so that the
author could specify the title of the window:

@viewport {
  title: "CSS3 Basic User Interface Module";
}

Of course the title of a window is often considered content (and even
metadata by those folks who see all attributes as metadata), thus it makes
sense to instead provide a way for such a 'title' property to point to
wherever in the content the window title is specified, perhaps by using a
selector in the value:


@viewport {
  title: contents(html>head>title);
}

Where the contents() functional expression evaluates the selector on the
document and retrieves the text contents of the element chosen by the
selector, in this case, the <title> element that is a direct child of a
<head> element that is a direct child of an <html> element.

Such a mechanism would be one way to style the titlebar of windows that
present arbitrary XML documents, since XML does not itself have an
<xml:title> element which browsers could use automatically (unlike specific
vocabularies like XHTML and SVG).


Tantek

Received on Sunday, 16 May 2004 17:00:23 UTC