Re: CSS Futures

James Elmore <James.Elmore@cox.net> wrote:

>WHAT IS DISPLAYED: HTML / XHTML documents may contain text, images, media, and 
>active objects (such as applets and JavaScript). I believe that the ability to 
>display data (lists, tables, 3-D data sets, graphs of data, etc.) is missing 
>from this group. CSS needs tools to help format and display sets of data. Lists 
>and tables are a start, but are simply too little to provide display and 
>formatting of data sets. Perhaps data can be automatically formatted into graphs 
>or charts. (I have seen this trick done with scripts and SVG, but some simple 
>formatting controls in CSS would be better.)

This is about content first, so it should have specific markup, see:
http://www.whatwg.org/specs/web-apps/current-work/multipage/section-phrase.html#the-meter
http://www.whatwg.org/specs/web-apps/current-work/multipage/section-the-canvas.html#the-canvas

IMO CSS should be able to handle the visual presentation of both. I
particularly have a problem with the Javascript dependency of the canvas
element.

>     Some of the content of blocks requires object controls. Audio needs start, 
>stop, rewind, and volume. Video needs audio plus full screen, small, larger, 
>etc.

Again a content issue first, see:
http://www.whatwg.org/specs/web-apps/current-work/multipage/section-video.html#audio
http://www.whatwg.org/specs/web-apps/current-work/multipage/section-video.html#video

Here again I have a problem with to the Javascript dependency for the
player controls, but this is not for CSS to solve.

>Block content larger than will fit requires scroll bars.

CSS2 overflow property: http://www.w3.org/TR/CSS21/visufx.html#overflow

>Future 
>improvements (e.g., 3-D data sets -- see above) will require other object 
>controls. There is no way to style these controls in CSS. I am aware that the 
>CSS WG has decided that these controls are the responsibility of the UA people. 
>I believe CSS needs to rethink this. All of the companies for whom I have 
>produced user interfaces required a company 'style' for their sites, which 
>included object controls as well as font and backgrounds. If this is not 
>possible in CSS, it has to be hand coded in Java or other web language, which 
>makes CSS much less useful. If CSS is really about presentation, users need to 
>be able to style controls. Simply waving hands and saying 'this belongs to the 
>browser people' won't make this problem go away.

CSS3 proposes allowing the styling of UI controls:
http://www.w3.org/TR/2004/CR-css3-ui-20040511/
Both the styling of scroll bars and form elements are included.

Note that when UI controls are drawn by the OS, styling options may be
limited.

>     Block sizing control is extremely limited. Only tables allow users to take 
>both block content sizes and screen width into account when displaying blocks 
>and automatically size the contents. This has been an ongoing discussion, but I 
>thought it worth repeating. I would like to see block sets (perhaps a class 
>where all the blocks are sized by CSS).

Again, we already have tables (HTML or CSS) that provide shrink to fit
behaviour. The very qualities that make them easy to use also makes them
a decidedly sub optimal method of creating a layout. There is no point
in allowing table like properties outside of the current CSS table model
when they are destined to replicate all of the problems associated with
tables used for layout.

>     Block alignment tools are missing. Text can be aligned on baseline, top, 
>bottom, etc. Block alignment controls should allow the left borders to align 
>(vertically), or the top of one parallel to the bottom of another (horizontally).

CSS3 selectors and negative margins or relative positioning currently
allow adjacent borders to overlap. Please provide a real world use case
if you have a situation where this does not suffice.

>     Block placement is also limited. Outside of a table, either blocks are 
>'inline' and go with the flow of text, or they stack vertically. I see some 
>steps in this direction in the new specifications. I would like to propose 
>simple layouts, along with the advanced ones being considered. Things like 
>frames

The "client side inclusion" feature of frames is generally regarded as
fundamentally broken, and CSS2 already allows simulating multi pane
layouts.

>or simple grids (X rows, Y cols; next X*Y elements are placed in the 
>grid), can be very useful in almost all cases. Don't forget that very few 
>designers need the advanced features and will be happy with simpler ones, 
>provided those simpler features are available sooner.

A proposal to spec something like a "simple layout module" should imo
not be considered unless the spec writers believe that such can reach
implementable status considerably sooner than the advanced layout module
/and/ when implementers believe that there is a problem with
implementing the advanced layout module due to complexity /and/ when
there is no risk of replicating the problems that table layouts suffer
from.

>     Right now, block margins and padding determine spacing of block objects and 
>their contents. However, different rules apply when the blocks are floating, 
>inline, in a list, or in a table. The controls which allow CSS users to manage 
>interactions between blocks -- things like border overlap, margin collapsing, 
>child margins fitting into parent padding, background colors shading between 
>blocks, and so on, are missing from CSS.

Can't comment on that due to lack of a proper problem definition and use
cases. (snipped various other parts for the same reason)

>Back to the subject of controls (sliders, audio buttons, etc.): would different 
>controls work better on different media types? (Just one simple example -- on 
>audio-only devices, could headers be LOUDER since they can not show bold or ALL 
>CAPS?)

Rendering defaults should be left to UAs.

>     Some documents, like coupons, should not be displayed before / after 
>certain times. Some document information might be more or less important 
>(displayed larger or smaller) based on time of day or day of week -- ads for 
>nightclubs or breakfast bars, for instance.

This should be left to server side technologies or Javascript.

>Documents in general should use 
>larger fonts at night, for easier reading.

A case (ludicrous imo) to be made to UA manufacturers.

>     Some consideration has already been given to the length of time media 
>objects are displayed, using SMIL. Can SMIL or SMIL-like syntax be applied to 
>styles, to make text (or objects in general) expand and/or move? This would 
>allow CSS (and possibly XHTML) to eliminate <marquee> elements, since any object 
>could be styled and tied to timing behaviors, such as scrolling off a screen. 

Dynamic behaviour is the preserve of Javascript.

>Even <blink> could be eliminated and replaced by SMIL-like controls which change 
>the element color or make it transparent.

CSS2.1 has text-decoration:blink
http://www.w3.org/TR/CSS21/text.html#lining-striking-props

-- 
Spartanicus

Received on Tuesday, 3 July 2007 08:08:21 UTC