RE: Proposal: display-order for serialization display order

There are definitely some major problems with your proposal that would need
to be resolved.  For example, what happens in pathological cases such as:

#a {display-order : before(b)}
#b {display-order : before(a)}

This would be well-formed and yet is total nonsense if treated
unthinkingly.  At the very least, the before(id) and after(id) values will
have to be resolved into other values when computed values are evaluated. 
There are further potential pitfalls that need to examined but that can
only be done if how 'display-order' is to be evaluated and how the actual
values are used is more precisely detailed that you have shown on the CSS
list.

Furthermore, your concerns about screenreaders and search engines are IMO
better handled by proposing changes to how the source document is marked-up
so as to identify those portions included for navigation than by making
changes in how the source document is styled as you propose.  For example,
the <nl> element found in the XHTML2 working draft addresses those concerns
directly rather than indirectly as your proposal does.

Personally, I feel that if CSS does include a property to allow display
order to be styled it should work not in the manner that you have proposed
by changing the display order of the element that the property is attached
to , but rather to allow a display order other than FIFO for the children
of an element.  Something along the lines of:

tbody {sort-order: col-key(3,content,alpha)}

to order the tr's of an (X)HTML tbody element alphabetically by the
contents of the 3rd column.  Such an approach has the advantage of avoiding
any inkling of recursion that even if carefully defined away, is likely to
cause confusion.

Received on Saturday, 18 June 2005 18:29:39 UTC