13 Aug, 2011, Twisol wrote in the 41st comment:
Votes: 0
RoFAdmin said:
The loader as others have pointed out should not determine what properties, and property values are valid or do anything with them, because the loader is unaware of what the renderer will do. The loaders soul job is to make sure data is loaded in to the objects in a manner that is consistent with CSS standards.

The loader doesn't need to know what properties are valid, because all properties share a common syntax.

RoFAdmin said:
It is then the job of the renderer to decide which properties are valid, and how their values are converted.

The renderer can decide how the values are used, but there is no way for "2px solid red" to be interpreted except as a sequence of [dimension, identifier, identifier]. It's wasteful to re-parse the same string into the same exact values every time the property is used.

RoFAdmin said:
you can not expect the loader to pre-know variable types

I can't? CSS is a language. This language defines a variety of data-types, and syntactic notation to demarcate these data-types. You can't add a new data-type to CSS.

RoFAdmin said:
CSS Web Class
someclass{
padding:14px;
color:#CCCCCC;
}
CSS Mud CLass
someclass{
padding:5;
fore-color:CYAN;
}

Pedantry, but 'someclass' isn't a class. '.someclass' is. There's nothing wrong with your comparison, but 5 is syntactically a number, and CYAN an identifier. There's no reason to store them both as strings.

RoFAdmin said:
In addition there is nothing saying that the value of a property can not be some function that needs to be equated at the time of rendering that line.

You're right. I just looked up some CSS functions, and there's one called attr() that gets the value of an attribute for the matched node. However, that doesn't mean you can't store the function and its parameters as a Function syntax node, and evaluate it during rendering.

RoFAdmin said:
Now if you are talking about compliance with variable names between web and mud. Thats a whole different story and has nothing to do with my compliance with CSS in general.

And if you must know yes, I do plan on using the same names as the web related ones, i just used the ones above to prove a point about not knowing variable types ahead of time.
I actually plan to use both web related property names, as well as using xml elements for the structure so that it is possible to bypass the server handling of the data and let the client do the work.

I really don't see a problem with this.
13 Aug, 2011, RoFAdmin wrote in the 42nd comment:
Votes: 0
Really what your getting at is you feel I should separate the property values out if there are multiple one and determine actual values in functions are called before i call the render-er.

Which has absolutely nothing to do with the original arguments, and isn't specified in the CSS standard anywhere as to when this would be done. So at this point I would have to go with you are either trying to argue a difference in opinion of when it should be performed, or are just attempting to try to find something to nit pick at.

It really comes down to a matter of choice as to where you chose to determine the value of a property. Doing it at render time allows for great flexibility i think.

As far as code goes, could you show me some C code for a single PROPERTY structure that would hold multiple unknown amounts of property values each with different unknown types that the C code can easily access? Pretty sure anything you can come up with is gonna get rather bloated to achieve something rather simple in teh end making it easier to store it as a string and evaluating as needed.
13 Aug, 2011, Twisol wrote in the 43rd comment:
Votes: 0
RoFAdmin said:
Which has absolutely nothing to do with the original arguments, and isn't specified in the CSS standard anywhere as to when this would be done. So at this point I would have to go with you are either trying to argue a difference in opinion of when it should be performed, or are just attempting to try to find something to nit pick at.

It really comes down to a matter of choice as to where you chose to determine the value of a property. Doing it at render time allows for great flexibility i think.


property
: IDENT S*
;
declaration
: property ':' S* expr prio?
;
prio
: IMPORTANT_SYM S*
;
expr
: term [ operator? term ]*
;
term
: unary_operator?
[ NUMBER S* | PERCENTAGE S* | LENGTH S* | EMS S* | EXS S* | ANGLE S* |
TIME S* | FREQ S* ]
| STRING S* | IDENT S* | URI S* | hexcolor | function
;
function
: FUNCTION S* expr ')' S*
;
hexcolor
: HASH S*
;

http://www.w3.org/TR/CSS21/grammar.html

Anyways, I'm just saying determine the -type- and -parts- of the value. Deferring the actual evaluation is fine, and in the case of functions crucial. I just don't think it makes sense, at all, to re-parse "rgb(255, 255, 255)" every time you use it. (Again, I don't care about
http://www.w3.org/TR/CSS21/grammar.html

Anyways, I'm just saying determine the -type- and -parts- of the value. Deferring the actual evaluation is fine, and in the case of functions crucial. I just don't think it makes sense, at all, to re-parse "rgb(255, 255, 255)" every time you use it. (Again, I don't care about [i[evaluating[/i] it, just determining [i]what it is[/i].)

[quote=[url=/topic-3523-57673#p57673]RoFAdmin[/url]]As far as code goes, could you show me some C code for a single PROPERTY structure that would hold multiple unknown amounts of property values each with different unknown types that the C code can easily access? Pretty sure anything you can come up with is gonna get rather bloated to achieve something rather simple in teh end making it easier to store it as a string and evaluating as needed.[/quote]


[code]
// legal CSS types - not an exhaustive list
enum css_value_type {
STRING, UNIT, FUNCTION
};

// single CSS value
struct css_value {
css_value_type type;
void* value;
};

// property name + values
struct css_property {
char* name;
css_value* values; // list of values
};[/code]
14 Aug, 2011, RoFAdmin wrote in the 44th comment:
Votes: 0
Yeah i thought of that about 1 minute after i posted i could just make another structure for the values. Loads in in backwards with a linked list, but that's easy enough get around.

I suppose it would be easy enough to have the render-er run through the objects once before actually doing rendering. You do make a valid point, I submit on this one.
15 Aug, 2011, Runter wrote in the 45th comment:
Votes: 0
I mentioned it before, but I'm going to say it again. I really love sass.

http://sass-lang.com/
http://sass-lang.com/docs/yardoc/Sass/Sc...

And for sass to work I'd have to use fully compliant CSS. (Because that's what it compiles down to.) So that alone for me, and I bet other users for other reasons, would be a deal breaker. I think it's a great example of why people should go out of their way to follow existing standards. Presumably we don't know the needs of the users of a codebase. Presumably we don't even know what our own needs will be in the future. That's why we write maintainable, extendable and, most importantly, modular decoupled code.
15 Aug, 2011, donky wrote in the 46th comment:
Votes: 0
I think this is one of the more inspiring ideas posted in a long time. I can't help but think how it might be incorporated into my code-base. Particularly interesting to me, is the idea of ditching custom solutions and adopting ubiquitous standards making something hopefully more maintainable and easier to approach.

If I can find a CSS/HTML processing solution I can drive from Python, hopefully I can also find some time to play around and see where it might be taken.
15 Aug, 2011, Tyche wrote in the 47th comment:
Votes: 0
How many views does a mud have?
15 Aug, 2011, Runter wrote in the 48th comment:
Votes: 0
Tyche said:
How many views does a mud have?


I think you could consider every command a view potentially. A lot of them might fall back on a generic command template. I also think you could consider pushes from the server a view. Such as random zone messages, channels, people leaving and entering the room, etc etc. Not to mention skills, combat, minigames. So I bet it would swing wildly from mud to mud as to what they might consider a view to be. (And what they'd want to template against.)
15 Aug, 2011, RoFAdmin wrote in the 49th comment:
Votes: 0
@runter

All one would have to do is write something to load in css formatted files in to the existing data objects and it would still work with the render-er. As i said, im not writing something to parse css formatted files cause i would much rather work on a render-er first.

And if it were that important, i could easily write something to convert a css file to the format im using to load the data with and thus sass would work.

@tyche
I wasnt sure where your question about views was directed. Im thinking at me as i think i said something about views in an earlier post. As for how many views a mud could have it would really depend on how generic of an output the mud uses most of the time. In theory though each function that outputs data could be its own view, or generate and output multiple views.
15 Aug, 2011, Runter wrote in the 50th comment:
Votes: 0
RoFAdmin said:
@runter

All one would have to do is write something to load in css formatted files in to the existing data objects and it would still work with the render-er. As i said, im not writing something to parse css formatted files cause i would much rather work on a render-er first.

And if it were that important, i could easily write something to convert a css file to the format im using to load the data with and thus sass would work.

@tyche
I wasnt sure where your question about views was directed. Im thinking at me as i think i said something about views in an earlier post. As for how many views a mud could have it would really depend on how generic of an output the mud uses most of the time. In theory though each function that outputs data could be its own view, or generate and output multiple views.


Lol, okay. You keep doing what you're doing. I'mma keep telling people to not do what you're doing. I'm pretty sure we find each others actions in that regard equally offensive.
15 Aug, 2011, donky wrote in the 51st comment:
Votes: 0
Runter said:
Well, I wouldn't want to write it all in C myself, but I don't see why it would be super hard to leverage a library already written for us.

http://sourceforge.net/projects/htmlcxx/

Of course, just about anything in C is going to be harder to write, but that's the sacrifice C demands.

Unfortunately, it does not appear to be cross-platform compatible. Why this is, I didn't discover. Maybe it does, and the example application does not for some reason support Windows.

#ifdef WIN32
if(parse_css)
{
cerr << "Css parsing not supported in win32" << endl;
return 1;
}
return 0;
#else
I did manage to find two C CSS libraries, one is the MIT licensed libcss and the other was the gnome libcroco project. Both have burdensome dependencies, and the latter is unfortunately LGPL.
17 Dec, 2011, donky wrote in the 52nd comment:
Votes: 0
Anyone done anything further with this?
19 Jul, 2012, Runter wrote in the 53rd comment:
Votes: 0
donky said:
Anyone done anything further with this?


The idea spun into a query engine that I use very often using css selector, sort of like jquery in js. I haven't used it much for actual presentation rendering, well, because I'm using a web based approach. And I've found it easier just to serve css to the web browser rather than translating the css to broad concepts and then using another set of css on the client using those concepts. If I implement a traditional interface I'll probably use it, though.

Also, I think it got lost in the wall of text I posted here a year ago, but here's the working prototype for the system.

https://github.com/jeffreybasurto/css4rb
40.0/53