Trying to build a module: CSS-Scripting

[Brian Nickel]

I'm trying to put together a proposal for a CSS module: CSS-Scripting
I would appreciate comments/ideas.
[code:n63d5njzq6]<style>
html {
background: enum {
url('tl.png') no-repeat;
url('br.png') 100% 100% no-repeat;
};
}
.valign {
padding-top: math( ( self[height] - self[content-height] ) / 2 );
}
.right {
position: absolute;
left: math( self->parent[width] - self[width] );
}

/* body width via code */
math( getElementsByTagName(html)->item(0)->firstRenderedChild[available-width] )
</style>[/code:n63d5njzq6]

I don't know if any of this has been created yet but:
content-(height|width) is the size of the actual content.
available-(height|width) is the size of the element, inside padding, border, margin.
outer-(height|width) is the size of the element, outside padding, border, margin.
math( ) calculates values with standard DOM.
firstRenderedChild, renderedChildNodes, and things of that nature is CSS that ignored display:none; type directives.
enum {} allows for multiple entries in definitions that can reasonably support it (pretty much just background right now).

<font face="Courier New"><font color="brown">>++++++++[<++++++++>-]<++.>++++++[<++++++++>-]<.[>+>+<<-]>---------.--------.>----.</font id="brown"></font id="Courier New">

[hzr]

Yea, looks interesting. Sometimes you want do something like half of the browsers width + 20px.

<font face="Courier New">-- David</font id="Courier New">

[Garrett Smith]

getElementsByTagName(html)->item(0)->firstRenderedChild[available-width]

I think that it would be better to have a selector for root node. html is a language name. You'd have to have a selector for each language and that would make css too divergent.



~ + * the root element ("~" nothing followed by "*" any element)
> * the first child
~ + * > * root element's first child

I can understand how they left out "~" selector. Zero is a difficult concept.

css 3 has a rule for content-box or border-box. It offers limited flexibility. It probably won't even be usable for four years (practically). I can see how equations would be handy. Max-height and Min-height are handy, too, but don't work in IE.

enum is a good idea:

cursor: url;
cursor: pointer;
cursor: hand;



[url="http://dhtmlkitchen.com/"]Garrett needs a job[/url:6lta47pw4x]

[Brian Nickel]

<blockquote id="quote"><span class="smalltext" id="quote">quote:<hr id="quote">I think that it would be better to have a selector for root node. html is a language name.<hr id="quote"></blockquote id="quote"></span id="quote">This was simply for an example. documentRoot (or a similar name) could be used in its place, as it is DOM. Your examples would also work, I haven't decided to go by symbol or text basis yet.

<blockquote id="quote"><span class="smalltext" id="quote">quote:<hr id="quote">It probably won't even be usable for four years (practically).<hr id="quote"></blockquote id="quote"></span id="quote">This is the one property that everyone felt important. Both IE and Mozilla currently support it (moz does -moz-box-sizing though).

<hr>

I've decided to expand enum to handle switch cases:
[code:nr4p58co74]@media screen:sunny
{
body { background: orange; }
}
@media screen:stormy
{
body { background: black; }
}
img
{
border: enum
{
sunny: 1px solid red;
stormy: 2px solid blue;
default: 0;
};
width: enum
{
100px;
200px;
300px;
};
}[/code:nr4p58co74]

In if no case is set for enum entires, they will all be tested, in cases where only one solution will work, the last successful one will be the one used.

I'm not sure where we would fit the case definitions, maybe <style type="text/css-scriptable" css:class="stormy">

<font face='Courier New'><font color=brown>>++++++++[<++++++++>-]<++.>++++++[<++++++++>-]<.[>+>+<<-]>---------.--------.>----.</font id=brown></font id='Courier New'>

[simu]

looks interesting and very usefull, have to take a closer look at it in the near future...

---
Simon Käser
admin@endlessX.com
http://endlessX.com

[Sergi]

yeah, very nice and handy idea. expression is somewhat limited.

<font color="green">
Sergi: </font id="green">[url="http://meddle.dzygn.com"][meddle][/url:ge4ao7ge3k] <font color="red">v2 READY</font id="red"> || [url="http://gen7es.net"][gen7es][/url:ge4ao7ge3k] || [url="sergi@dhtmlcentral.com"][e][/url:ge4ao7ge3k]

[Chris]

good stuff.. some of it is similar to some other proposals in the CSS3 spec though, like this:

[code:bpbeffms5t]
div#links li:nth-term(even) {
color: red;
}
[/code:bpbeffms5t]

that would make all even numbers in the list red... pretty good huh?

[url="http://chrispoole.com"]Chris[/url:bpbeffms5t]

[aboodman]

one thing i would really like to see is the ability to use xpath expressions as selectors in css. it frustrates me that there are two competing node selection syntaces, expecially when one is so obviously superior to the other.

i realize there are probably technology issues associated with applying style to random xpath expressions, but it could certainly be a subset.

i don't see how:

[code:vxtfwrb09k]
div#links li:nth-term(even)
[/code:vxtfwrb09k]

is better than:

[code:vxtfwrb09k]
div[@id='links']//li[childNumber() mod 2 == 0]
[/code:vxtfwrb09k]

yeah it's longer, but it's more expressive. we don't need more and more nouns to express similar concepts. i've already harped on this, but is there some reason nobody seems to agree with me?

most importantly, modern browsers already have xpath engines built in? why support two different syntaxes?

// aaron
// aaron@youngpup.net
// http://www.youngpup.net

[ttrenka]

What a great idea. I wonder if the people who do CSS specs don't talk to the people who do XPath...

[Brian Nickel]

I think they're just trying to rationalize pseudo-elements.
Their only use that can't be done through XPath is really along the genre of :hover :active and :first-line objects, and if they just had that it would seem kind of shallow.

<font face='Courier New'><font color=brown>>++++++++[<++++++++>-]<++.>++++++[<++++++++>-]<.[>+>+<<-]>---------.--------.>----.</font id=brown></font id='Courier New'>

[Chris]

the people who make the specs for the different technologies need to keep in their heads what the technologies are for, and keep focused to that. CSS is overlaping with XLink.. the DOM comes into some CSS3 properties.. they need to realise the use of the differnt techs, and stick to it. if they keep on going down the roads they are now, we'll end up with more and more grey areas, and less standards.

aaron: the CSS alternative is no better than the XLink 'alternative', but if you just want to style some of the objects in certain ways, maybe the CSS way is preferred? XLink can do so much more though, and has many other uses...

[url="http://chrispoole.com"]Chris[/url:8wt1bpsnz1]