Omnipotence, render order styles

Posted on Wed, 14th December 2005 at 14:31 under Eureka!, Publicity

On omnipotence, could an omnipotent being create something over which it had no power?

On render order styles. I want three new CSS styles; “render-before”, “render-after” and “render-with”. Each style may be applied to any block-level element. Each style takes a list of element ids. An element styled with “render-before” will be rendered before each of the elements in its list. An element styled with “render-after” will be rendered after each of the elements in its list. An element styled with “render-with” will be rendered or not in the same way as each of the elements in its list. Lists given to any of these styles must not contain the id of the element being styled.

8 Responses

  1. Can we have this in english please?

    Reply
  2. Note the category of the post. These are things that come to me in the bath. However, as you have requested clarification, here goes.

    The first paragraph is the correct form of the age-old aphorism that goes If God is all-powerful, can He create a rock even He cannot lift?

    The second paragraph refers to an idea I have to relax the last remaining restriction on HTML rendering in browsers. Consider the following HTML file…

    <html>
    <head><title>Render order styles test</title></head>
    <body>
    <div id='first'><p>This division is rendered first</p></div>
    <div id='second'><p>This division is rendered second</p></div>
    <div id='third'><p>This division is rendered third</p></div>
    </body>
    </html>
    

    At the moment, all browsers will render the paragraphs sequentially as read from the file. It is possible, using absolute and relative positioning, to control where the divisions will appear on the page but it is not possible to control the order in which the page renders.

    Now consider the following stylesheet to be applied to the above HTML…

    #third { render-before: “#first” }
    #second { render-after: “#third” }

    With this style, the HTML paragraphs will be rendered in the order; third, second, first. I appreciate it may not seem like much to laypeople but the effect on the relationship between the browser and the data it renders is profound and could be very useful indeed. HTML files would cease to be ordered lists of rendering blocks and become homogenous sets of block-level elements with weak, default ordering.

    Does this help?

    Reply
  3. Yes, it now makes perfect sense. As a relative lay person when it comes to web programming I am not immediately enlightened as to it`s application, however I`ll take your word for it.

    Reply
  4. Thanks for encouraging me to explain.

    As to application, these tags would provide a simple way to organise blocks of text on a page and to rearrange them, at will, in the browser, without requiring a trip back to the server every time. This can kinda already be done to some extent with absolute positioning but I’m not keen on that - it gets too messy.

    Reply
  5. This place called Protopage lets you move write notes and move stuff around. Apparently it uses Ajax - now I thought that was for cleaning floors……

    http://www.protopage.com/v2

    Reply
  6. This is simply the old omnipotence paradox. A good response is to say that setting a challenge which an omnipotent being could not rise to is a logical impossiblity and so cannot be done even if you are omnipotent.

    I like the computing angle - haven’t considered it like that before.

    Reply
  7. Another aspect of the paradox involves the relationship between omnipotence and time i.e. can an omnipotent being a) be in more than one place at one time (omnipresent), and therefore b) do more than one thing at one time (omniperformant)?

    As to the render order styles, I proposed them on the w3-style mailing list and got an immediate kick-back as being not a style matter. The W3C Style Working Group have been asked about the idea before and won’t consider it, even though page authors are asking for something like it. Here’s the e-mail exchange I had,

    Reply
  8. Paul said:
    I have recently started tracking CSS3 developments and found the advanced layout draft very interesting. The proposal is rather more complex than my modest needs. Forgive me if a similar idea has been covered before (or, heaven forfend, already exists), but this is all I’m after; simple render order styles.

    I do not pretend to have analysed this idea to death, only so far as I could explain the intent to a non-programming friend.

    Orion said:
    This breaks incremental rendering so it won’t be implemented.

    Paul said:
    I don’t understand your objection. Are you asserting that page authors must never be allowed control over UA render order? Surely incremental rendering is an ideal, not a requirement.

    Orion said:
    I’m not objecting, they did. I personally find the CSS algorithm and XML structure system very flawed, but they do rule the world these days so I try and participate where I can be useful.

    Paul said:
    Thanks for the clarification. I’m perfectly happy for the right standards to rule the world because I can always choose not to use them. I’m aware of some of the possible ramifications of render order control but I’m not so happy for artificial restrictions to be placed by the standards on potential uses that could be beneficial. So, if I still think I have a case to argue after reading the previous exchanges on the subject, I shall do so.

    Orion said:
    If you read past incarnations of this request (it pops up every 3-6 months or so), you’ll see the reasononing behind it each time is that it would break incremental rendering.

    Paul said:
    I’m totally new to the list. Can you recall the names of such threads or help me with some common phrase I can use to search the archives? I would love to read the background.

    Orion said:
    Unfortunately not. I looked a bit, but I can’t remember the names of any of them. The background, to summarize, is that incremental
    rendering is what allows documents to be rendered as the source comes in over the wire. Any thing that breaks incremental rendering
    prevents this behavior and is considered a deal breaker. While there are a few instances of selectors that do violate this, the working
    group has said many times content reordering isn’t something it’s ever going to allow.

    Paul said:
    That’s exactly what I need to know. If render order is not a matter of style then it is not a matter for the style standards group. My question then becomes, which standard covers render order? The style group are punting and I’m sure the HTML and XML groups won’t catch because they deal with structure, so who does?

    Any ideas, Orion? Is there a pressure group I can join? Am I missing a standard? I won’t accept that this just “falls through the cracks” because it is far too important an issue. I’m not prepared to accept linear rendering as the only way just because no-one wants to deal with it defining another way. That makes render order a de facto standard, something I thought the w3c was constituted to avoid. “Any colour you like so long as it is black” is not something I like to hear these days. :)

    Orion said:
    Ir’s most likely the domain of XSLT as has been said before. If your content isn’t in the correct order, something must reorder it before it gets to the styling stage. Your other option is absolute positioning, which doesn’t really work.

    Paul said:
    Well there’s the issue. Correct order for content need not necessarily be the order of transmission. I may be able to transmit my content more efficiently in a different order than it is to be rendered. As an analogy, subroutines in programming code.

    Orion said:
    A file that isn’t in source order may be more efficient on the server end, but it’s less efficient on the client end in terms of rendering.
    While the algorithm could be changed to allow for what you’re talking about, it won’t be. The working group has been fairly consistent on
    this issue. I can’t point you to any supporters of this idea within the group. The idea, of course, has had some support outside the
    working group, but that support is limited and unlikely to change things.

    Paul said:
    Absolute positioning does not reorder content. XSLT rewrites content which is not always the most efficient way to reorder, especially for large documents. Reordering is a corner-case where presentation is changed but a server round-trip for content is known to be unnecessary. If the content is unchanged but presentation is altered, that seems to me to be a matter of style, hence my proposition for a stylistic standard.

    Whom on the style working group do you think might be receptive to argument about UA-level content reordering? Is it truly a championless cause? :)

    Orion said:
    Their suggestion is that any content reordering should be done on the server before content is sent to the client or after it’s sent via
    xsl-stylsheets.

    Paul said:
    I’ve had a ponder about content ordering in light of our conversation.

    What I am seeking is a client-side “content assembly protocol” which, being a form of decompression, is properly a matter for content standards, not style.

    Thank you very much for your help. I can now seek a solution in the correct domain.

    Reply

Leave a Reply

You may also log in to post a comment.

XHTML:

If you want to <q>tag</q>, please balance these; a, i, em, b, strong, u, blockquote, q, ul, li, ol, abbr, code, pre, sub and sup.