11 Aug, 2011, Runter wrote in the 21st comment:
Votes: 0
CSS is agnostic about the data. What the fields are makes little difference. I don't think there's any gain to be had by supporting only specific attributes. So I'm not sure what you're actually proposing. Only allowing certain attributes? CSS is designed so that even technically invalid attributes are given to the renderer. The renderer determines if they should be used or not. But the parser still parses the entire document out. Generally you'd only have to parse/compile the css tree one time anyways. (Or when the css is changed.)

How the renderer uses the css is completely out of the scope of the CSS specification. CSS does, however, specify how things should cascade. And it demands an XML type model. In other words, you need nodes with children.
11 Aug, 2011, David Haley wrote in the 22nd comment:
Votes: 0
If I understand this correctly, the point here is to output structured data to an intermediate renderer that happens to use CSS as its rule engine to determine how to format that data. So, sure, you don't necessarily need to support all of CSS. And yes, it's unclear how some things would even translate to a terminal-based renderer (such as floating div positions). But that's ok; the point is that CSS is just a renderer layer for arbitrary (structured) data.
11 Aug, 2011, RoFAdmin wrote in the 23rd comment:
Votes: 0
I was thinking that if only certain attributes needed to be handled it might be easier to write something to read it in that was less weighty then a full CSS parser. That was all.

I saw you linked a library for parsing them already for c++ though I'm unsure if every language has something similar already done for them.

And while supporting extra properties isn't bad, if those are the only properties that would apply, supporting extras isn't needed either, so someone wanting to use the basic concept you are suggesting may not feel the need to write a full css parser to implement the same kinda thing your talking about. I was simply asking the questions of if there was more attributes that people could see being useful?

Which also leads in to whatever code your going to use to apply the rules. If those are the only attributes that apply, that is the only thing that code really cares about.
Plus if i know the attributes i need and expect when reading it in, anything else is wrong (probably a typo) and i can inform someone there is a problem with it.

The reason I was asking is i downloaded a stock ROM base and was going to write up a simpler parser for it.
While pondering the process, i was thinking of the best way to go about this.

What would make most sense is to make use of the functions that ROM has available for me already for reading in and parsing files as this
would cut down on code that i need to write to do this. This however immediately means not actually parsing CSS format.
This however does not mean the same concept of CSS cant apply.

So this of course led me to say ok, well if im going to use ROM's built in functions to read in these files what properties would i be needing?
This doesn't mean it wouldn't be easy to add new properties later as needed, it just makes it easier to put something together in a stock ROM.
This just means writing less code, and ensuring proper format in the files it reads.

Relax man, Like i said, i like the idea, and I'm try to contribute something useful here. For one of the already admitted most pain in the butt languages/code-base combos there is. Yeah it has to dumb down the idea some, but its a fair trade off that provides the same concept your talking about.

This also means though that I need to write the render as well. Which as I said is easier to do if I know what properties to expect already, and can easily be expanded to add more.

The render itself is independent of what parsers in the data, so now any C language would have a render that could use the concept of CSS to style and format up their display and expand as needed to incorporate new properties.

So can anyone think of any other properties that would be needed?
11 Aug, 2011, David Haley wrote in the 24th comment:
Votes: 0
Parsing CSS is not the problem; if you're going to limit the CSS you support, it would be in the rendering portion.

This doesn't really have to be a big standardized process; support the attributes you want to support in your rendering, depending on what your end output is.

If your end output is to a web browser, you might even not render anything and just send HTML/XML + CSS to the browser.
11 Aug, 2011, Runter wrote in the 25th comment:
Votes: 0
I boggled by this entire conversation, honestly. If an attribute is one the renderer doesn't understand then you can do whatever you want with that attribute.

My point is that only supporting a few of the attributes won't change the "weight" of the parser. Unless you're just suggesting not parsing CSS at all. But youre not talking about losing just attributes. Let's be clear, you're talking about losing a majority of the features CSS has.

Why would you want to use a subset of CSS? There's CSS parsers, and usually multiple ones, in just about any language you can think of. It would be foolish to use a subset on a whim. I wouldn't use CSS at all if I were having to write my own parser. It's not practical. It's also not practical to have to tell the builders which parts of css you've decided to disregard. And I promise you there's a lot more to CSS than we've discussed on this site. And I think it should all work, including the pseudo class selectors like n-th and children, etc etc. Those are implemented for you in a proper css library.

Furthermore, not using the full CSS spec (at least 2.1) would be foolish for other reasons. Like you can't use an awesome dynamic CSS language like SASS that compiles down to compliant CSS with the power of a programming language.
11 Aug, 2011, RoFAdmin wrote in the 26th comment:
Votes: 0
Maybe if I make the explanation and questions simpler.


1) Im going to write the actual rendered for the use of CSS in C, The render-er has no relation ship to what actually parses in the CSS data initially. SO thus you have two separate things.
Whats parsing the data in, and what is handling the display of what was parsed in.

2) In order to write a nice render-er id like to have something functional to work on it in. ROM is a nice widely used C codebase, and since im using ROM to speed up getting data in for me to render its easier to use ROMs code for reading in files. So thus NO I would not be parsing in actual css formatted files. There is no reason that does not mean things like pseudo class selectors and n-th and children wouldn't be supported. Your assuming because I want to read in a limited set of properties that im wanting to limit how it functions elsewhere… which doesnt make sense.


3) Since im writing both what is going to parse in my css data, and render css, why not make the parser handle only properties the render-er is gonna need to deal with? What sense does it make to have what is parsing in my data handle something my render-er is not gonna make use of? If someone else wants to handle parsing in CSS formatted files then feel free there isnt anything to say that it wont work for rending still. The render is still only gonna handle what it knows about though.

4) So since im writing a render-er that leads me to the questions. What properties should be supported? This has nothing to do with anything other then the actual PROPERTIES for the rendered, and im my particular case what IM doing to read in MY data. See how i still need to know what sort of properties would be supported, and how they should handled…. It kinda needed for a render-er
11 Aug, 2011, David Haley wrote in the 27th comment:
Votes: 0
Quote
3) Since im writing both what is going to parse in my css data, and render css, why not make the parser handle only properties the render-er is gonna need to deal with?

I don't get why you keep coming back to this.

If you write a parser that can read CSS, you will parse all CSS no matter what you actually do with it.

Parsing is separate from processing/rendering. It's more work to force your parser to validate CSS against your subset of understood attributes than it is to just parse the darn thing.

Quote
4) So since im writing a render-er that leads me to the questions. What properties should be supported? This has nothing to do with anything other then the actual PROPERTIES for the rendered, and im my particular case what IM doing to read in MY data. See how i still need to know what sort of properties would be supported, and how they should handled…. It kinda needed for a render-er

I don't really understand this question either. Support the ones that you want to support. Don't support the others. This doesn't need to be, and I daresay this should not be a big standardization effort.
11 Aug, 2011, Twisol wrote in the 28th comment:
Votes: 0
Bluntly: We want to use the syntax of CSS, not the properties defined by the web-specific usage of it. CSS defines a flexible model for defining rules and properties, but doesn't define any itself. For example, look at a rule like "div > p {}". What is div? What is p? They're node names defined by HTML. CSS doesn't care what they're actually called.

In the same way, CSS is agnostic about what properties you define and use. What it does care about is the syntax of these properties and their values, which must conform to various the data-types that CSS supports.

EDIT: The communication issue here is that, to date, the only serious production use of CSS is in the browser realm, which is why we call the most recent set of CSS attributes "CSS3" instead of "CSS3 Web" or some such thing.
13 Aug, 2011, Deimos wrote in the 29th comment:
Votes: 0
I don't think he understands what parsing involves, which is probably the root of the confusion. It seems that he is under the impression that a parser would look for particular properties (color, width, etc.) rather than valid tokens ([a-z0-9-]+ or whatever it happens to be).
13 Aug, 2011, Twisol wrote in the 30th comment:
Votes: 0
Here's the syntax section of the CSS 2.1 specification. ("All levels of CSS level 1, level 2, and any future levels use the same core syntax.") It might be useful to glance over the tokenization section to get an idea for how CSS' syntax works.
13 Aug, 2011, RoFAdmin wrote in the 31st comment:
Votes: 0
NO Deimos, what it is is people seems to not actually read everything I type, and make bad assumptions

Ive already stated im NOT parsing in CSS formatted files, and that i have NO interest in doing that, and someone else can if they want
Ive stated im using ROM and its built in functions to read in files, which is WHY im not using css formatted files


Below is what a properly formatted style would look like in a css file


div ol>li p{
some_property:value;
another_property:value;
}


Below is what the file im using to read the data in looks like cause its easier to parse with ROMs built in functions then write the code to actually parse a css formatted file.

div ol >li p~
KEY VALUE
KEY VALUE
KEY VALUE
KEY VALUE
#

See the difference? See how the second one would be WAY easier to get ROM to read in?


Contrary to what David Haley said, It easier to write something to parse of my data files using ROMs built in functions then write the code to parse an actual CSS formatted file. As you can see there is nothing lost about CSS in my format and it took me about 5 minutes to write the code to load in the data.

As I also said, i have no interest in writing a parser for CSS formatted files. What I do have an interest in is writing a render-er for text using CSS rules to stylize it. Which is why i opted to go with using crappy data format and ROMs built in functions. Allows me to get data in to the code to work with quicker.


As far as me asking what properties a render-er would support, it was a simple question to see if there was anything I was overlooking that may apply to how text is formatted in your standard client. Instead of saying hey "background_color" would be useful, i got an postseemed to make it pretty clear what I said wasn't either all read or understood.


The real issue here twisol, is that people dont seem to get that just because data being read in is not formatted to how CSS is typically that it still can be applied in the same manner once loaded in or that by not having the same format, i am somehow omitting functionality from the render-er. Both of which are untrue. I'm simply using a different format which makes getting the data in easier given the tools that ROM had available already so that I can begin work on writing a render-er.

Since the render-er is separate, once im done with it, there is nothing to say someone couldn't write a parser for CSS files. They would just need to load the data in to the appropriate objects in the code. Maybe they are assuming the objects in the code have some sort of relationship to the format of the data in the file, but that would be a bad, and wrong assumption.

Below is the way the data would be stored in the code.
struct css_class{
char *selector;
CSS_PROPERTY *property;
CSS_CLASS *next;
CSS_CLASS *next_in_view;
}

struct css_property{
char *name;
char *value;
PROPERTY_DATA *next;
}


The actual code supports adding whatever properties you want to a class. So thus unused properties could be added, im simply not bothering to make the parser im writing read in data it doesnt need to be aware of because its SIMPLIER and QUICKER to get actual data in that way to write a render-er.

Is there anything else here that doesnt make sense to anyone?
13 Aug, 2011, Runter wrote in the 32nd comment:
Votes: 0
Quote
Is there anything else here that doesnt make sense to anyone?


This isn't CSS with these changes. Given your example above you changed { to ~ and } to #. This doesn't make sense to me, no. If you're going to take the time to invent a CSS parser, which is a daunting task, but only slightly modify it. It doesn't make sense. In other words, see the next paragraph.

Quote
The real issue here twisol, is that people dont seem to get that just because data being read in is not formatted to how CSS is typically that it still can be applied in the same manner once loaded in or that by not having the same format, i am somehow omitting functionality from the render-er. Both of which are untrue. I'm simply using a different format which makes getting the data in easier given the tools that ROM had available already so that I can begin work on writing a render-er.


You seem to be saying you're going to have all of the css functionality with a slight change in format. I don't believe you. I don't think that you are implementing a full spec css parser with all of the functionality, because they're tons of work. Enough work that it would totally eclipse whatever benefits you think you're getting from using some rom function to read a string from file.
13 Aug, 2011, RoFAdmin wrote in the 33rd comment:
Votes: 0
@Runter

1) Im not taking the time to invent a css file parser. What i took was the time to throw something together to get data in to the program so as to write a render-er.
2) There is only one example that i can think of given my change in format that the parser doesn't handle. The would be the @rules, specifically @import which other @rules rely on. All that does is include another style sheet into the current one. So yes i guess there is one minor functionality I have left out of my parser in order to get data in to write a render-er. Can you supply me with another one?
3) I think your getting confused here with the parser for the data being read in, and what is going to actually parse the text to be stylized and apply the rules to it. Parsing the list of loaded already data to find the rules that apply is the complicated process, and what deals with the selectors, cascading, and inheritance.
13 Aug, 2011, Twisol wrote in the 34th comment:
Votes: 0
RoFAdmin said:
2) There is only one example that i can think of given my change in format that the parser doesn't handle. The would be the @rules, specifically @import which other @rules rely on. All that does is include another style sheet into the current one. So yes i guess there is one minor functionality I have left out of my parser in order to get data in to write a render-er. Can you supply me with another one?

CSS defines standard data-types that a property value must conform to. Your format handles the rule definition acceptably, but you're left with a string key and a string value. What about CSS functions? rgb(255, 255, 255) is one that certainly might be useful. Or dimensions? Those are the CSS numbers-with-units, such as '2px' or '1em' or even '3ch'. You're reading in a list of properties, but you still have to parse the value data or else be limited to numbers and identifiers.

That said, if you just want a CSS-like way to render a tree, as long as you get the inheritance and cascading working it should be fine. Those are a bit more difficult than a mere parser, though.
13 Aug, 2011, Runter wrote in the 35th comment:
Votes: 0
The full benefits of C without having to write a C compiler. That would be assembly right? Assuming the "benefits" just means "can accomplish the same task."

CSS is grammar. If you really want to see all of the things that is part of the CSS spec, I suggest you go look for yourself. It's easy to hand wave the benefits of a certain grammar, just because you already have a turing complete tool. Which, I still don't believe, btw. But, here, we all know that different languages give you different amounts of power in expression. I think you are going to have to implement a css selector parser sooner or later, and that is part of the CSS grammar. You can delegate stuff and push the work on the renderer, and claim it wasn't part of the CSS parser. Whatever. I can read in a full file with one call, validate nothing, and claim I just write a minimal parser for any format. That's not different from what you're claiming here.
13 Aug, 2011, RoFAdmin wrote in the 36th comment:
Votes: 0
@runter

I know whats part of the spec. You finally just realised what im beeen trying to explain to you the whole time. I was simply talking about reading the data in from the file in to the program so i could write the render-er which would do the actual parsing of the css rules based on the selector data. Which is where the rule for that particular class is stored. The only thing im missing in my already admitted NON CSS file parser is the ability to handle @import statements which has nothing to do with the rules on the classes themselves so is irrelevant since i said im not writing something to handle in reading actual css formatted files.

Quote
I think you are going to have to implement a css selector parser sooner or later, and that is part of the CSS grammar. You can delegate stuff and push the work on the renderer, and claim it wasn't part of the CSS parser.

Really, im gonna have to implement something to parse the css rules?I never would of thought it. What do you think the rendered is doing? It has to check the rules and see what applies.

What does reading the data in from a file have to do with parsing the actual rules? Nothing.
How would you go about parsing the rules before you have a context for them? You wouldn't, you do it when you are given the data to be formatted and build a view based on the rules that match the data to be formatted.


@Twisol
Yes, the value for the property is stored in a string when it is read in for the the exact reason you mention.
Values can be a wide array of types, and even themselves call on functions that in turn give them their value. How else would you store this when read in to C?
It is the job of the render-er to both determine the rules that apply and determine the value of the property since it is the render-ers job to determine both if and how that property applies, and if and how the value of the property is valid and applied.
13 Aug, 2011, Twisol wrote in the 37th comment:
Votes: 0
When one speaks of "parsing", usually one means "transforming a textual set of data into a more useful internal format". The data is thus in an easily-used format that can be used later by, say, the renderer without doing any extensive interpretation of the data. A "context" matters not at all, except insofar as the renderer applies the rules to a subject.
13 Aug, 2011, RoFAdmin wrote in the 38th comment:
Votes: 0
@twisol
That is what i did, i took the file and parsed it in to a more useful internal format. And thus the data is in an easily used format that can be used later by, say, the renderer without doing ay extensive interpretation by the data.

What is extensively being interpreted? Once you know what the property is, you can determine the value quiet simply. Sure it may call a function. But CSS does not specify where the returning value of the function is to be determined. It could be handled ahead of time in whatever is parsing in the file, but doesn't have to be. And certainly evaluating it when its needed is within the scope of the specifications.

You still didnt answer the question at all. Given the variety of values that a property can have. What data type would you store their value in?

You could of course make a valid property data type for each type of property value, but then that complicates the entire process of parsing through the variables of a class, which is no better or worse then figuring it out when you need it.


[edit] Unless your saying i could validate the data. Which im pretty sure was already stated (and not by me) is not the job off anything to do with css. It simply specifies the acceptable values for the properties. It would thus make it the renders job to validate properties and their values…[/edit]
13 Aug, 2011, Twisol wrote in the 39th comment:
Votes: 0
RoFAdmin said:
You could of course make a valid property data type for each type of property value, but then that complicates the entire process of parsing through the variables of a class, which is no better or worse then figuring it out when you need it.

It's basically just an AST, and yes, that's what I'm suggesting. Storing something as "2px solid #FFFFFF" means you have to reprocess the string each time, when you could instead turn it into [new Dimension(2, "px"}, "solid", new Color(0xFFFFFF)]. Also, you'll need a way to check if "!important" is at the end of the value, because that's not part of the value - it's a flag saying "this value is important".
13 Aug, 2011, RoFAdmin wrote in the 40th comment:
Votes: 0
The loader and render-er are two seperate things for all intensive purposes. What links them are the data objects.
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.

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

TO prove that point i bring up what you said about people just thinking of CSS as CSS Web, when thats not the case. CSS can be used in many places just the web is where its used most. Since there are many different things that can use CSS and not just the web, you can not expect the loader to pre-know variable types, and proper values as a proper loader should handle loading the data in to the objects without this knowledge.

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

Those two classes would essentially achieve the same thing. Why? Cause the web class is designed for web browsers, which have determined that padding is a variable, and the proper variable format requires a unit type. The Mud Class would be designed for the theoretical render-er that im working on and would in no way need to ahve the same properties, or variables types as a web browser. Thus a proper load would care nothing about any of this and leave the job up to the renderer.

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. Thus my render-er could incorporate some function that is 100% within css standards (but not supported on browsers) and uses values require at processing time. This is shown with the different properties available even amongst web browsers, all still valid css data to be loaded, just doesnt apply to that particular render-er.


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.
20.0/53