Comments on: CSS or just MESS?

By: bobef

bobef — Wed, 03 Feb 2010 07:41:04 +0000

It is funny. I agree IE5/6 made a lot of difference. Plus they could be used for desktop applications. At the time they were so ahead of everything else. On other hand IE6 was holding back web development for years.

In principle I can add support of ‘root’ value to the display-model model attribute so you can define something like:

It would look better IMO, but it doesn’t matter much. It was just a thing that came to my mind.

By: Andrew

Andrew — Wed, 03 Feb 2010 02:59:50 +0000

To bobef about HTML5. Standartization is a good thing for the Web of course.

But let's compare:

http://dev.w3.org/html5/markup/ (circa 2009) and
http://www.w3.org/TR/html4/ (circa 1998)

not that much I would say. To wait 10 years for things like is simply not acceptable. Better than nothing of course.

I strongly believe that the whole principle of such development is plainly wrong.

The golden age of web technologies development was the time when browsers were fighting for the market by adding features. IE5 and IE6 added a lot to what we have now. E.g. main thing behind AJAX http://en.wikipedia.org/wiki/XMLHttpRequest#History_and_support was added by guerilla methods of Outlook Web Access team (OWA is the best online email application IMO).

This time Google is pushing new features under the umbrella of HTML5. Pretty much in the same way. I remember it was an even an attempt make SQLite specification as a part of HTML5. No objections to the SQLite per se but in HTML? All this smells not so good.

I would rather to see minimal specification (HTML4 was pretty solid spec IMO) but with extensibility mechanism. Just allow to specify something like this:

input[type=datetime] { behavior: datetime; }

With the ability to hookup your own script based implementation if your browser does not support 'datetime'.

You can put separate spec for things like 'datetime'. It will be significantly better as we can update specs for behaviors after month of public discussion or so. But not another 10 years ...

And about ``,``, etc. tags in Sciter. ( BTW: they are optional in html :)

In principle I can add support of 'root' value to the display-model model attribute so you can define something like:

window 
{ 
  display: block; 
  display-model: root; 
}

and so your markup may look like:

..

nothing difficult. If it matters.

By: John

John — Mon, 01 Feb 2010 22:50:00 +0000

Agreed. No language should ever work like that, but I don’t think it is beyond repair yet. It is possible to unify the representation of lists without breaking backwards compatibility, because there ARE a handful of characters that could be used without a problem. You could use {} or () for grouping. If John the Web Designer can understand the current system, but can’t comprehend grouping with curly braces, he must have something wrong with him.

The thing about using {} to fix this is that it doesn’t conflict with existing syntax. Currently, nothing uses {} in a single style. (Though it looks like wobble is trying to kill this option too?) I’m not sure how existing parsers will feel about it, but if they follow the standard about ignoring things they don’t understand, I think they should be fine, right?

You’ve participated in CSS development a lot in the past. Any chance you could convince folks to fix this before it’s too late?

By: bobef

bobef — Mon, 01 Feb 2010 10:27:46 +0000

HTML5 may help web applications, but don’t forget these [web] people are stuck with what the least common denominator (i.e. IE) has to offer. Even if this was not the case they are pretty stuck. I mean all they have is javascript/html. They can’t extend the browser. They need to consider how google crawler works. They often need to consider how the web server works. So they kind of need this standards otherwise it becomes a mess. We on the other hand are not writing web application. Even if we are, we are not executing them in the browser, but in our own client (based on HTMLayout/Sciter) over which we have infinite (well almost) control. So my point is HTML is a nice readable way to define layout. CSS is a nice readable way to define some visual properties of this layout. They both are a good way to appeal to wider audience and make it easier for them to get started. That’s about it. I don’t know if all the HTMLayout users have the same opinion as me, but I like to do my own stuff. You see at first I was trying to stick to my web programming habits while using HTMLayout, then I realized I don’t need to stick to retarded habits because this is never going to be a web application but a desktop one and I have much more power at my fingertips. It is my own thing and I don’t need to make it compatible with IE or old server software or google or whatever. So it is good to have some web compatibility to get started. Later it is good to be able to get rid of all that and do your own stuff the way you like. Right now I use master css from scratch and all kinds of custom tags to do various things, so my html editor thinks all my tags are wrong and displays them in ‘wrong tag’ color. But it suits my logic and likings. In fact I want to get rid of as much builtin/web standard stuff as possible to get maximum performance and maximum ‘the way I like it’ markup. For example – why on earth would anyone want to write ‘html’,'head’ and ‘body’ tags in a desktop application? They are completely useless (unless they do some good to internal h-smile workings which I’m unaware of). You just need to include your styles/scripts/tag definitions at the top of the document. There is no ‘title’,'meta’ or whatever. Even if there is you will have your own way of processing it. If you like these in a head tag – fine – define your own head tag and put them in it. It takes only few lines… The list of examples goes on. There is a lot that can be done to aid applications (applications as opposed to pages). But my opinion is that this should be more in the form of libraries/modules. The host should be very basic, but extremely fast and [easily] customizable.

By: Andrew

Andrew — Sun, 31 Jan 2010 21:33:44 +0000

Yep, I am with you, Borislav.

But what about HTML5 ( http://www.w3.org/TR/html5/ ) ?

“In this version, new features are introduced to help Web application authors, new elements are introduced based on research into prevailing authoring practices”

HTML5 is targeted towards applications – not just to support of formatted text, HTML4 was good enough on that, IMHO.
So presumably HTML5 should help? But that is just a markup language at the end …

By: bobef

bobef — Thu, 28 Jan 2010 09:05:08 +0000

Luckily TI’s product is not a web browser, nor anything that has to be web compliant. Actually I was thinking (again) the other day what “the ultimate” gui toolkit should look like. Sciter is almost there in my opinion and where I think it fails is the web complicity – it has too much of it – only wasting performance and wasting tags that could be otherwise used. In my opinion H-SMILE should be based on HTML/CSS, but only on the good points, only where it makes sense, because it is a well known syntax. But nobody is going to port their web portal to Sciter for offline use.

The purpose is entirely different. The only place where HTML/CSS is actually needed is a help system or something similar that will display formatted text. All these many tags and inline stuff make little or no sense for application gui. It is all blocks and layout-ing these blocks. Maybe there should be something like a single element that support HTML formatted text and images. HTMLayout is layout defined with HTML-like syntax, not HTML page, because it is not a page. So display: block, blocks-inside for the win . IMHO it is much more important to have some drawing definition language (you mentioned it once). Something that can easily handle many layered drawing operations and animation. This could change how things are done in a great way. Then one wouldn’t need to stack elements one upon the other to simulate layers and stuff. One would just need blocks and the right layout. Then CSS selectors combined with some drawing rules can do the rest. I see no reason why H-SMILE should follow behind w3 rules. I don’t do lot of web programming recently, but I feel seriously retarded when I need to go back to CSS and Javascript DOM and all that browsers provide. It is plain stupid thing compatible with something made 10 years ago meant for displaying text…

My point is H-SMILE is more than enough web compatible. It is not embedded browser. Trying to follow new web standards (if they are not particularly useful) is going back IMHO.