Re: Proposal: display-order for serialization display order

> NEED:
> A property that sets the serialization display order of a selector within a=
> 
> parent element without affecting the document flow, independent of the
> source-code.

In my view this encroaches too much on XSLT.  It also is particularly
bad for progressive rendering.

> 
> 
> PROPOSAL:
> display: inline | first

The display property already exists.

> block | last
> .... | before(id)
> | after(id)

As noted, you then have to define what to do with circular references.  Given
that web browser developers don't like error conditions, you also need to
define the edge cases when id doesn't exist or is not on a sibling element.

Another point here is that CSS stands for Cascading *Style Sheets*.  Style
sheets work best as style sheets when you use classes rather than ids. 
With ids you can only use one style structure in on a page.  That
may not be too much of a problem for the current use case, but is still
a bit restrictive.

> | number

It's not clear whether these define a strict or partial ordering relation,
but you need to define what happens when multiple items are first and when
multiple items are before or after an element.  You also need to define
how inline interacts with placed elements.

> 
> As shorthand for the property display-order

As noted above, display is an existing property.

> BACKGROUND and BACKWARDS COMPATIBILITY:
> Web developers want the main content in a document to be as close to the
> start of the document as possible for mainly two reasons:
> 
> 1) Accessibility reason:
> The nature of screenreaders forces serialization of a document - therefore=

Actually, it is the nature of the internet that forces serialisation.
Having important content first is desirable because it allows the user
to react to that content (e.g. backing off the page if it isn't useful)
before the whole page has loaded.  However, your proposal isn't really
compatible with the progressive rendering that that requires.

>From a progressive rendering point of view it worse than the recent
vertical centering proposal because the fix-up that is required isn't
a simple reflow of the contents, so it cannot sensibly be done on the
fly and can cause a radical movement of content, confusing the user, if
done when page loading is complete.  That only really leaves delayed
rendering, which means the content isn't available early.  It's also
a good way of getting people to back off your site before any of the
page has been displayed.

I know that most table based layouts also suffer delayed rendering, but
I think that that is often because the designers are unaware of 
table-layout: fixed.
> 
> the document will be read from start to bottom. Being able to change the
> order in which element displays will allow source-code to be optimized for=
> 
> both screenreaders and other browsers via media stylesheet.

The sort of assistive technology that is typically referred to as "screen
readers" but is really a lot more, currently acts as though it were always
using visual media types.   (That's because it is designed for use on
real world web sites and for use as an alternative to making internal
web sites really accessible.)

> Also independence from source-code order would achieve freedom for
> webdevelopers and remove practical limitations of CSS for layout.

That's definitely in the XSL domain, not the CSS one.

> 
> Backwards compatibility:
> Focus on implementing display-order first, then the display property. This=
> 
> way webdevelopers can incorporate display-order in their pages without
> worrying about their statement being ignored as 'invalid CSS' by error
> handling when used in display: property.

If you really mean overloading the existing display property having it
ignored as invalid is desirable.  You should always code using older
syntax before the new syntax.  Basically you can never assume that
you are not dealing with a browser that doesn't implement a new feature.
Features are often not implemented for commercial reasons (IE won't implement
new features in the foreseeable future), many ordinary people do not
upgrade and there are many people using firmware browsers that have
long lifetimes and no great upgrade path - the manufacturer has quite
possibly gone out of the market.

> Content-Type: text/html; charset=ISO-8859-1

No its not.  Real HTML has title elements and DOCTYPES and uses <p>
properly.  It's better not to post HTML to public lists.

Received on Sunday, 19 June 2005 19:41:36 UTC