Ogre Forums

Like who designed this sh**e language or whatever you want to call it? I mean why can people just set absolute or real position's of element in html? Like CSS was supposed to fix all this, But its just a stupid. Like you have to control the position of an object in the middle of a div, Using the thickness of the div's border. What a waste. Why not just something like position-real-x: 100% etc?

Sorry about this, But i get so frustrated, and wonder why this "language" is designed in such a shoddy way.

Cheers

Scratchy

You mean something like "position:absolute;"?

I think it was pretty good initially, but then every other person inserted some functionality till it got a big mess, then instead of starting over they just put css on the top of it to make it even worse (Kind of like the strategy to introduce a new language and libraries over Win32 API ). I wonder what would've happened if TeX or simmilar system was chosen instead back then

XML, derived from the HTML language, is a step in speculative direction as well - it means an easy interchange of information, yes, but it could have been way simpler. Example is google protocol buffers:

Protocol buffers have many advantages over XML for serializing structured data. Protocol buffers:

* are simpler
* are 3 to 10 times smaller
* are 20 to 100 times faster
* are less ambiguous
* generate data access classes that are easier to use programmatically

scratchyrice wrote:and wonder why this "language" is designed in such a shoddy way.

It isn't... It's just a basic markup language for assembling a web page. The only tag which you should be using (most of the time) is the <div> tag; there's nothing else to it. The rest should be done in pure CSS.

The only thing I would agree on is if you complained about the cross-browser compatibility of CSS, which quite frankly, is a nightmare.

DanielSefton wrote:The only tag which you should be using (most of the time) is the <div> tag; there's nothing else to it. P

Agreed. Once you get into the whole semantic web thing going on, and get used to the idea of separation of content and presentation - it becomes worth it. I mean nobody here embeds their Ogre Meshes in their C++ code right?

Cross-browser compatibility seems to be getting better; there are tons of css/html frameworks to work from now (960.gs is one of my favourites), and other hacks or tricks are well documented now. But these sort of things should never exist in the first place, if people followed to specification.

volca wrote: XML, derived from the HTML language

This is incorrect. XML was not derived from HTML at all. It is a subset of SGML (actually, both XML and HTML are subsets of SGML).

W3C wrote:The Extensible Markup Language (XML) is a subset of SGML that is completely described in this document. Its goal is to enable generic SGML to be served, received, and processed on the Web in the way that is now possible with HTML. XML has been designed for ease of implementation and for interoperability with both SGML and HTML.

http://www.w3.org/TR/2000/REC-xml-20001006

Oh, good point.

Still - my opinion does not change - XML is ineffective and bloated language which is hard to process and write code for (or maybe it's just the libraries I used so far), and finds many ill uses in the industry

Sure I know it is very practical as an data interchange format. A the place where I work we often receive XML full of good intentions and bad implementation practices - as an example - change in XML formatting breaking client's software

volca wrote: Still - my opinion does not change - XML is ineffective and bloated language which is hard to process and write code for (or maybe it's just the libraries I used so far), and finds many ill uses in the industry

Sure I know it is very practical as an data interchange format. A the place where I work we often receive XML full of good intentions and bad implementation practices - as an example - change in XML formatting breaking client's software

As you point out, it's not the fault of the markup language used -- humans can screw up anything, regardless of its features to prevent same.

The primary reason that it is so used in so many places, is that it uses a very regular syntax for which many many parsers exist, all of which are robust, tested and mature -- so it becomes the proverbial hammer looking for a nail, and rather than write yet-another-custom-file-parser, many elect simply to use XML (granted, sometimes in places where it's not the most appropriate choice).

But again, human misuse is not the fault of XML. (I could go off on a "guns don't kill people" analogue here, but I won't )

You're right about that - it's a user's fault to misuse some technology As you say - people often choose XML just because it's common and easily accessible. There are places I can hardly understand the motivation, though - for example ant build files

volca wrote:for example ant build files

I'm with you on that one.

Oh, curiously ant is the only build system, I really feel comfortable with. Whether this is because of xml or inspite of it, I don't know.
I like the well structured, tidy approach over the linear "dump everything in, where ever you like" approach of makefiles/cmake and such. Insofar I can imagine, that XML helps to keep it up. And of course Eclipse helps a lot too.

I like 'premake'. I tried CMake once, and I think the only time I'd use it is for distribution of software. premake is a good quick utility for in-house builds.

XML is the proof Vogons are real and among us. I too dislike it with a passion. One of the things I really love on Ogres .material files, they are C style and not bloody XML, making them very clear and readable and my eyes don't have to wade through the double amount of characters including markup brakets and slashes - yuck!

HTML is ok tho, relatively easy to pick up and as said before if you stick to divs and css you can keep it at a minimum if you wish, and by now you no longer have the horrible cross browser differences and work-arounds you had years ago.

Nauk wrote:XML is the proof Vogons are real and among us.

I avoid listening to Vogon poetry, I avoid looking at XML.
But I use XML. When appropriate. As long as I don't have to look at it.
Like serialising components, behaviour trees ... Well, at least until the format settles. Then a tailored format, be it binary or textual.

I'm a loyal google protobuf user, and I only use XML for simple user-editable data files.

nullsquared wrote:I only use XML for simple user-editable data files.

You are evil!
I use ini/text files for that, because I am a nice guy.
Even a text protobuf file is better than XML.
IMO.

jacmoe wrote:

nullsquared wrote:I only use XML for simple user-editable data files.

You are evil!

Sounds like we found a Vogon!

I use Lua for human readable ini files.

I've been using html and learning javascript and css stuff for the last few days, trying to make some greasemonkey scripts (specifically for work tomorrow).
Trying to extract arrays of data from pages filled with unnamed tables inside of tables inside of tables inside of tables and then draw coloured bar graphs is tricky. Html really should have some primitive graphics operations built in. I ended up supplying 1x1 pixel gifs as inlined data uris then stretching them to make bars. End result looks good, but it was painful to use trial and error to work out how this stuff works. A dom explorer would have been handy (is there one for firefox? mozilla had one built in), as well as tables with ids.

Kojack wrote: Html really should have some primitive graphics operations built in.

HTML itself shouldn't -- that's what JavaScript is for.

There's always DHTML - but it's old now.

Kojack wrote:I ended up supplying 1x1 pixel gifs as inlined data uris then stretching them to make bars.

That's where CSS comes into play : http://nicholascook.net/demos/graph/

DanielSefton wrote:

Kojack wrote: Html really should have some primitive graphics operations built in.

HTML itself shouldn't -- that's what JavaScript is for.

No, Javascript would be horrible for that, and very difficult to come up with a suitable "file-format" of code.

We have the new canvas tag and SVG vector and bitmap operations.

jacmoe wrote:

nullsquared wrote:I only use XML for simple user-editable data files.

You are evil!
I use ini/text files for that, because I am a nice guy.
Even a text protobuf file is better than XML.
IMO.

No, XML is better suited for this type of thing due to tags. The data is not a simple list of property name and property value.

But I would switch to a text protobuf file if that's possible. Is it? I only thought that it was possible to display output of such a file for debugging purposes; I'm pretty sure you can't parse such a file w/ google protobuffers.

That css graph thing looks interesting, but how well does it work as a post processing grease monkey script, since I have no access to modify the actual web page to include graph.js, the Prototype framework, etc.

A data uri (firefox and maybe ie8 only) being used to make a box of whatever size I want: Actually there's a loop in the middle which strings a whole bunch of those img bits together to form the bars, this is just a simplification.
I would have prefered a box tag or something. If html can do text and images, why not easily do a coloured rectangle?
Then again maybe it can, I really have near zero interest in web based stuff and just wanted a quick hack. Of course if I show the other staff I can do javascript, they might try to make me teach it or something.
(I made a mistake at a previous job of putting on my resume that I could do databases (I knew sql). So they put me on one, upgrading a horrendous VB5 app connected to Access. Not knowing VB or Access made things tricky. At the same time they took the VB/database coder and put him on a C++ project. It freaked the other staff out when I started writing queries in the sql designer instead of using the drag and drop bit)

███████████████████████████

Coloured rectangle, you called?




...

boost::serialisation is pretty nice. Serialisation of pointer members in GameObjects has always been a problem, but I've fixed it using alternative means of addressing GameObjects (in NGF every GameObject has a unique 'ID' number).

nikki wrote:boost::serialisation is pretty nice. Serialisation of pointer members in GameObjects has always been a problem, but I've fixed it using alternative means of addressing GameObjects (in NGF every GameObject has a unique 'ID' number).

I still use pointer members (shared_ptr's to other "connected" game objects), only my serialization uses names.