Re: CSS Futures

David Woolley wrote:
> 
> James Elmore wrote:
> 
>> that the ability to display data (lists, tables, 3-D data sets, graphs 
> 
> 
>>     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.
> 
> 
> One of the key design principles of HTML is that it provides basic
> capabilities that allow one to produce usable documents for many 
> purposes without having to learn and understand a complex language (the 
> amount of copy and paste coding that goes on indicates that even even 
> professional web designers can't handle complex language rules).  3-D 
> data sets seems to me to be a specialist use, and the other paragraph 
> quoted appears to me to require a specialist advertising language.

Rather than argue that data sets and coupons are specialist applications, I 
merely wanted to point out things which CSS currently does not handle -- data 
and time-dependent elements.

Although HTML theoretically provides for the display of list data and tabular 
data, the elements are actually designed for text and image layout more than 
data display. Also, CSS does not provide the ability to style data, for example 
the way a spreadsheet would. (There is a provision in CSS3 where text-align can 
align on a single character, such as decimal point, but I see no way to easily 
handle dollars and cents, percentages, millions of units sold, etc.) 3-D is just 
an extension of this problem -- no styles for data elements -- which probably 
requires even more consideration to find a good solution.

Since the HTML/CSS languages do not provide simple ways to display sets of data, 
  we either need to provide ways to style data displays or refuse to consider 
that people displaying data might want to style their presentations. I saw a 
quote somewhere that stated, in essence, that the best way to style tabular data 
was with the <pre> element and judicious use of spaces. While that is certainly 
one way to display data, it is not the way most of us would choose, especially 
if we consider CSS as the correct tool to handle presentation.

As for the coupon example, I was simply asking myself if the question "When?" 
could apply to CSS stylings. It seems to me that there are people who might 
reasonably want to style their documents and have those stylings change in a 
time-dependent fashion. The examples I listed were silly and not given much 
thought, but the original question still applies -- is it reasonable to change 
CSS stylings in some time-dependent fashion? The group defining the SMIL 
features seems to think that time dependency applies to many topics in the W3C. 
Does the CSS group think it might apply to us? Yes, there are other ways to 
handle the examples given: javascript, server side scripting, and dynamic html 
are three possible solutions. But do we want to consider stylings changing over 
time -- they clearly do, but are they within the province of this group?

> 
> Rather than trying to bolt on features to support specialist uses, users 
> should be first checking to make sure that there isn't a less 
> fashionable tool that is designed for the application, and then create a 
> language that is optimised for that application.
> 

Yes, the examples given could be considered as specialist uses. But, as someone 
from this group told me last week, HTML and CSS were originally designed for 
white papers. Displaying data is an extremely important part of writing a white 
paper. And white papers often have portions which apply (or don't apply) to 
particular time periods -- describing particle research at CERN was the first 
use, I believe, and portions of research document might change from speculative 
to valid, or from valid to invalid, as further research is done.

My thoughts were simply to get us to consider areas which haven't been included 
in CSS before and to provide some possible rationales for including these new 
features. If a feature only applies to one small area, that might be 
justification for excluding it. But if the examples given are only for a small 
group but the features discussed apply to much larger groups, we should not 
immediately dismiss those features.

>>
>>     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> 
> 
> 
> If you are staying within W3C technologies, I would suggest that this 
> would be an SVG application, as I very much doubt that the average 
> author of such documents will care about accessibility.

I have seen, and used, SVG for this sort of thing. SMIL is already incorporated 
in their tool set. But, not only is SVG a new and rather difficult language to 
learn, it has, as you point out, problems with accessibility. My suggestion is 
rather more wide-spread than 'How can I do this?' I am asking, 'Can we do this 
in CSS? And, should we?'

My answer, at least for the moment, is that we should consider this ability. It 
would enable certain features which might be useful, without additional tags in 
HTML or additional styles in CSS. In addition, if we could style, for example, a 
text element as 'moving right-to-left slow' the much maligned <marquee> tag 
would no longer be needed to provide that effect for designers who REALLY WANT 
it (regardless of whether it is 'good' design). Additionally, users could set 
their own styles and disable this 'feature'.

> 
> Incidentally, marquee is an accessibility no-no, because it is 
> distracting and it is difficult for slow readers (including not native 
> language) to read.  That is why it wasn't retained as a presentational 
> element in HTML.
> 

If allowing time based control of CSS stylings is allowed, many new abilities 
will appear. Some of them will be very useful. Some of them will be very 
irritating (like <blink>). And some of them will be things that none of us could 
even imagine right now. Let us take some time and consider the possibilities 
which new features could bring to CSS. Even if this is not something to allow 
now (or in CSS3), they might be very powerful and useful additions in the 
future. Please don't dismiss these suggestions just because it is not something 
we want to do right now. Open yourselves to the possible and see where the path 
may lead.

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

Received on Tuesday, 3 July 2007 19:16:20 UTC