CSS Futures

Group:

I have been asked to post some of the things which might be missing from CSS. 
For your reading and discussing pleasure, here are some thoughts. Most are for 
the far future, but I hope to at least provide a target, a goal to head for, so 
we don't get lost in the details. Enjoy!


I was asked to summarize any deficiencies the Advanced Layout path would leave 
in CSS. I don't want to categorize my list as deficiencies, more like additions 
and improvements. Some of my suggestions will be clearly for far in the future. 
A few will, I hope, be interesting and useful enough in the short term that they 
can be adopted by the group and added to the a near-term specification for 
implementation.

I will try and keep this short, but some of the suggestions will require a 
little explanation.



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.) 3-D data might have a 2-D slice 
displayed with controls to move the view through the data set, by stepping, 
rotating in different directions, etc.



HOW THINGS ARE DISPLAYED: After text, the primary element type in (X)HTML is a 
'block'. Images, media, applets, paragraphs, and dozens of others are 'block' 
types. Blocks are reasonably well thought out, with content, padding, borders, 
and margins. Several of the problems I see with block elements are:

     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. Block content larger than will fit requires scroll bars. 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.

     Text styles have consideration for different types of displays (like 
font-smooth). There is nothing like this for blocks. Even something as simple as 
border-smoothing could be useful on small screens or ones with large pixels. 
Also, there should be consideration for printing versus screens -- if the image 
is photographed at 100 dpi, why scale the pixels for a 1200 dpi printer?

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

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

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

     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. Interactions between elements are well 
known in text objects (kerning, leading, white-space handling, a long list 
exists). Related interactions between block objects are missing from CSS.

If blocks are considered general-purpose content display elements, and CSS 
allows designers to control interactions between the blocks and to style the 
active controls which are needed for display of 'special' data types, many other 
style abilities become possible. If users need text flow between objects (often 
called 'text columns'), simply telling CSS that a set of blocks will contain the 
text from a paragraph and the text will fill the blocks at about the same rate. 
This would provide columns, rules between columns, spacing, backgrounds, and 
many other features, simply because blocks already are completely thought out 
display elements.

Further in the future, I would like the group to consider blocks which are not 
rectangular. Just as one example, triangular blocks could provide new layout 
concepts such as filling a circular frame and tessellation -- mosaic layout to 
fill a larger area.

I'm not sure if there is a project ongoing, yet, but there needs to be some way 
to simplify the extreme differences between display types using CSS. Could the 
group specify different default style sets for each different display type, so 
the designer only needs to list a few things in the style sets for printers, 
computer screens, cell phones, text-only displays, etc.?

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?)



WHEN IS IMPORTANT. Do we want to consider special rules which take time into 
account? (Yes, this is a topic larger than just CSS, it will require encoding 
time values into the documents and providing date/time information on the 
display device.) But many document displays vary in some time dependent manner. 
If the time information is available, what can/should CSS do with it?

     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. Documents in general should use 
larger fonts at night, for easier reading.

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




EVEN WHO might be part of the display: The person viewing the presented 
information might prefer to provide slightly more information to the UA and 
allow it to enlarge, reduce, or eliminate the display of things which either do 
or do not interest the reader. Far in the future, a person scanning want ads 
could declare herself to be female and no interested in 'Woman seeking Men' 
personal ads. (There are other ways to manage this, I know. This is just a 
thought about things that are possible using CSS, if the document creator 
provides more information about the document content and the document reader 
provides more information about interest.)




I can provide more complete details if my explanations are not clear. I can 
discuss the benefits (at least from my point of view) with anyone interested. If 
I had more time, I could probably come up with other areas missing from CSS. But 
this document is a starting point for discussion. It is not expected that all of 
the items listed here will be implemented, but I like to think that they will 
cause people to think and open their eyes to areas not considered before for CSS 
in the future.



Happy reading. Have a great 4th of July,


James Elmore
22162 Windward Way
Lake Forest, CA 92630
Home	(949) 830-9534
Email	James.Elmore@cox.net

Received on Tuesday, 3 July 2007 05:26:45 UTC