[whatwg] Side effects free scripts

[Alexey Feldgendler]

On Thu, 01 Jun 2006 14:27:11 +0700, Andrew Fedoniouk <news at terrainformatica.com> wrote:

> Consequence of "halting problem" is a Rice's theorem:
> it states that only trivial properties of programs are algorithmically
> decidable.
> "No side effects" is not a trivial property.

It's not necessary to verify that a script is side effects free at compile time. You can enforce it at run time with little effort, much easier than the full-blown sandbox approach.

>> To guarantee the same result each time is another requirement, and it's
>> not necessary to fulfil it. In the end, right now there are no guarantees
>> about the scripts, and wouldn't it be better if it could be guaranteed
>> that a CSS expresssion() doesn't steal cookies at least?

> Real example:  RegExp.source in IE is a static property. I think I don't
> need to explain how to steal cookies if I know that  regexp was used for
> analyzing them at some point.
>
> So answer is "no" on this:
> "if it could be guaranteed that a CSS expresssion() doesn't steal cookies at
> least"

Ok, let's take a closer look at this example. Please post such an expression that steals cookies using RegExp.source, and I'll show where the script should be terminated by the interpreter for violation of the side effects free contract.


>> The purpose of expression(), as implemented by IE, is to allow authors to
>> provide procedural implementation of the layout logic that the browser's
>> layout engine lacks. A simple example would be painting odd rows of a
>> table in one color and the even rows in another. Or highlighting cells
>> which contain negative values. Of course, those things that can be
>> expressed declaratively using CSS should be expressed as such, but there
>> will always be use cases beyound the current CSS. I think that declaring
>> alternating row colors with expression() is better than assigning them
>> alternating classes because these classes would be just "hooks" for CSS,
>> having no semantic value. And it plays better with dynamic tables which
>> allow rows to be inserted and removed.

> "cases beyound the current CSS" is a motivation to create better CSS but not
> to invent design struts. IMHO.

IMHO, they are motivation for both.

1. Not every use case is eligible for making a CSS feature. How far should it go? What if one needs to highlight rows in a table which fall under some complex condition? Some documents may need very unusual presentation which IS algorithmically derivable from semantics but is not expressible in CSS. I think it's better to have it specified with expression() rather than assigning presentation hooks such as classes to elements, and updating these every time when the content changes dynamically.

2. Even if a use case is eligible for making a CSS feature, it still requires time to make it into the major browsers. Many things which are not supported natively in IE can be implemented with expression(), and I think it would be good to have this tool for implementation of browser fallback in every browser.

> I've proposed two years ago flex units in CSS (aka %%).:
> http://www.terrainformatica.com/htmlayout/fspu.whtm
> http://www.terrainformatica.com/htmlayout/flow.whtm
>
> Two years of use prooved - they are extremely useful.

IE's expression() has proved to be useful, too. I think it's one of those cases like XmlHttpRequest when features implemented in IE prove useful enough to be standardized.


-- 
Alexey Feldgendler <alexey at feldgendler.ru>
[ICQ: 115226275] http://feldgendler.livejournal.com