On 05.10.2010 19:28, Walter Bright wrote:
> Stephan Soller wrote:
>> This is especially handy when doing a presentation about a programming
>> language since you can use JavaScript to write a small syntax
>> highlighter (the grammar in the D documentation was really handy for
>> that). :)
>
> A javascript D syntax highlighter? Please post!

I will extract it out of the presentation. But be aware, it's just a small tool I used to highlight the D code in my presentation about D. Don't expect something like a proper lexer. ;)

"Stephan Soller" <stephan.soller@helionweb.de> wrote in message news:i8i10k$2a86$1@digitalmars.com...
> On 06.10.2010 02:08, Arlo White wrote:
>> That's because HTML/CSS is a pretty terrible language for anything beyond simple layouts. It shares more with Word/PDF/PostScript in terms of its purpose and history than it does with real gui layout engines (GTK, QT, etc).
>>
>
> HTML/CSS is primary made for documents not applications.

So true. That, combined with HTTP's stateless nature (and the exploit-prone nature of trying to build state on top of it), is why I view "web as a platform" as being little different from using PDF as an application platform. Heck, the PDF spec is so open-ended it could certainly be done.

> If you want you can simply make every element a block level element and use JavaScript for layout. I don't know GTK and QT in depth but then you should have about the same level of possibilities as with these layout engines. It wouldn't surprise me if GUI frameworks like jQuery UI actually do this.

Heh, layouts that magically break with JS off. Fun :)

I bet you're right though that something like that is out there on the web (or will be coming).

You know what's even weirder, though? (And I hope on not veering too far offtopic with this...) I've actually some across pages that will load perfectly fine with JS off, and *then* two seconds after loading it will be automatically replaced with a different page that says "This site doesn't work without JS." Ummm, yea, it obviously *did* work...I *saw* it work...

>
> You can do quite a lot of stuff with the "position" property. As soon as you defined something as "position: absolute" you can move it around as you want. How well that (and other techniques) work depends on your HTML structure. However I have to agree that in most practical cases you have to modify the HTML in any way because the document structure changes.
>

Unfortunately, as soon as you start using "position: absolute", you usually start causing problems for resize behavior. Unless you're using a static-width layout which is generally considered bad style (for good reason).

That's one thing I've noticed about CSS layouts that I think a lot of web developers tend to overlook. You generally *can* get what you want with CSS as long as you assume page width is always the same. But once you decide "web pages should be dynamic width" and try to make it look correct at different widths, that's when CSS *really* starts to break down. Tables tend to resize far better, and give you far better control over resize behavior.

For instance, try to make a resizable box with bit-mapped borders that behaves reliably (I've needed to do a lot of that for a client recently). Easy as pie with tables and CSS background images. But with anything else in CSS, I've become convinced it's just not possible.

"Bruno Medeiros" <brunodomedeiros+spam@com.gmail> wrote in message news:i8hl00$1gv0$1@digitalmars.com...
> I found that:
> a) I had practically forgotten all the CSS/HTML rules and info that I had
> "learned" before, because they were so strange, complicated, and
> *unnatural* that there is now way you remember them unless you work with
> it on a daily basis.

I've been doing a lot of HTML and such, off and on, almost as far back as when Mosaic was still relevant, and I still spend most of my HTML/CSS-dev time with at least one browser tab opened to w3schools.com in the background.

On 07.10.2010 04:26, Nick Sabalausky wrote:
> "Stephan Soller"<stephan.soller@helionweb.de>  wrote in message
> news:i8i10k$2a86$1@digitalmars.com...
>> On 06.10.2010 02:08, Arlo White wrote:
>>> That's because HTML/CSS is a pretty terrible language for anything
>>> beyond simple layouts. It shares more with Word/PDF/PostScript in terms
>>> of its purpose and history than it does with real gui layout engines
>>> (GTK, QT, etc).
>>>
>>
>> HTML/CSS is primary made for documents not applications.
>
> So true. That, combined with HTTP's stateless nature (and the exploit-prone
> nature of trying to build state on top of it), is why I view "web as a
> platform" as being little different from using PDF as an application
> platform. Heck, the PDF spec is so open-ended it could certainly be done.
>

Never read the PDF spec, but I don't believe that it includes a world wide network of web servers, does it? From an application developers point of view I have to agree, HTTPs stateless nature is a bit problematic at first. However as soon as it comes to scalability the stateless approach saves you from _a lot_ of trouble. I can't think the Internet could be what it is with HTTP being design to be statefull.

With the advent of REST people not look at HTTP a bit more and realize that there is more to it than GET and POST.

>> If you want you can simply make every element a block level element and
>> use JavaScript for layout. I don't know GTK and QT in depth but then you
>> should have about the same level of possibilities as with these layout
>> engines. It wouldn't surprise me if GUI frameworks like jQuery UI actually
>> do this.
>
> Heh, layouts that magically break with JS off. Fun :)
>
> I bet you're right though that something like that is out there on the web
> (or will be coming).
>
> You know what's even weirder, though? (And I hope on not veering too far
> offtopic with this...) I've actually some across pages that will load
> perfectly fine with JS off, and *then* two seconds after loading it will be
> automatically replaced with a different page that says "This site doesn't
> work without JS." Ummm, yea, it obviously *did* work...I *saw* it work...
>

There is very much abuse or improper user of JavaScript in the Internet. Especially in the cooperate world where people usually don't have the time or are not willing to really understand the thoughts behind the tools they use (HTTP, HTML, CSS, JS). Business people are usually happy as long as it looks fancy. Even among professional web developers I don't know that many that really care much about the technical "correctness" of what they do. There are many ways to get the job done, who cares if it was a "right" one? (reminds me of a program I once hat to understand: it only used 8 global variables and lots of gotos… but it worked… and everyone was happy with it, except me).

Well, in the case to work with or without JS you have to make a distinction. A "document" should work all right without JS since its main purpose is to be viewed. However if you build a "real" web application in the sense of being more like a desktop application its almost a lost cause to make it work without JS. It will only cause a great deal of redundancy of code and an overcomplicated architecture. It is possible though if you really feel the need. However I would just stick to using JS and in conjunction with a REST interface. For a "application" this gives you a great deal of flexibility while still maintaining a simple architecture and good interoperability with other systems.

>>
>> You can do quite a lot of stuff with the "position" property. As soon as
>> you defined something as "position: absolute" you can move it around as
>> you want. How well that (and other techniques) work depends on your HTML
>> structure. However I have to agree that in most practical cases you have
>> to modify the HTML in any way because the document structure changes.
>>
>
> Unfortunately, as soon as you start using "position: absolute", you usually
> start causing problems for resize behavior. Unless you're using a
> static-width layout which is generally considered bad style (for good
> reason).
>
> That's one thing I've noticed about CSS layouts that I think a lot of web
> developers tend to overlook. You generally *can* get what you want with CSS
> as long as you assume page width is always the same. But once you decide
> "web pages should be dynamic width" and try to make it look correct at
> different widths, that's when CSS *really* starts to break down. Tables tend
> to resize far better, and give you far better control over resize behavior.
>

Actually tables prevent you from reordering your elements according to page size but this limitation also affects other techniques. To be honest I use fixed with designs a lot. Usually I just don't have so much content that I have to use every part of the screen. ;)

A while ago it was more of a problem but since the zoom functions of browsers evolved a lot it's not that much of a problem any more.

However there are ways to build flexible layouts. Usually it's considered good practice to use the "em" unit (size of a X in the current font-size) for your dimensions instead of "px". It's quite handy and gives you the ability to resize the entire page by just changing the font-size of the body element.

Reordering of main page elements according to screen size used to be very tricky (some clever combinations of float and overflow). I never really did it on a project tough. Today you can just use [media queries][1] to define different layouts for different screen sizes and devices (this is also quite handy to define layouts printing or for mobile devices). There is plenty of material on the web about this and I regular use it to turn small documents into presentations (by defining styles for the "projection" media type which is used by Opera in full screen mode).

[1]: http://dev.opera.com/articles/view/safe-media-queries/

> For instance, try to make a resizable box with bit-mapped borders that
> behaves reliably (I've needed to do a lot of that for a client recently).
> Easy as pie with tables and CSS background images. But with anything else in
> CSS, I've become convinced it's just not possible.
>

Actually is pretty easy in CSS. I also had to do it a lot in the past. You just nest as many elements (usually divs) inside each other as you need background images. Then you use one of those divs to create the border for one side: just assign a background image to this side and a proper padding that makes sure only this side is visible. Corners are a bit tricky to do no problem if you make the main container "position: relative" and then position the corner divs with "position: aboslute". However for most of my layouts I found that I didn't need a variable height and therefore 4 divs where sufficient. This method had it's troubles for IE 5 but in IE 6 you shouldn't have much of a problem (maybe one bug, don't remember exactly).

On modern browsers you can simply user border images (as many as you want). This also eliminates the need for semantically stupid HTML elements. However thanks to box-shadow, border-radius and colors with alpha transparency I hardly use graphics programs to design any more. I just do it directly in HTML/CSS with is usually quite a bit comfortable (and faster!). However these properties can slow down browsers quite a bit (at least Firefox). [This article][2] gives a good overview of what's possible already and where it is supported.

[2]: http://dev.opera.com/articles/view/beautiful-ui-styling-with-css3-text-shadow-box-shadow-and-border-radius/

Happy programming
Stephan

On 06.10.2010 16:26, Stephan Soller wrote:
> On 05.10.2010 19:28, Walter Bright wrote:
>> Stephan Soller wrote:
>>> This is especially handy when doing a presentation about a programming
>>> language since you can use JavaScript to write a small syntax
>>> highlighter (the grammar in the D documentation was really handy for
>>> that). :)
>>
>> A javascript D syntax highlighter? Please post!
>
> I will extract it out of the presentation. But be aware, it's just a
> small tool I used to highlight the D code in my presentation about D.
> Don't expect something like a proper lexer. ;)

Unfortunately I don't have the time right now to properly extract it and clean it up. I don't feel it good enough to be released here but well, here's the link to the presentation of a talk I gave about D1:


http://events.mi.hdm-stuttgart.de/archive/2010-04-13-d-einf%C3%BChrung/der-coole-stoff/Pr%C3%A4sentation%20(HTML).html

The syntax highlighter (search the source code for "syntax highlighter") was hacked together in a few hours. It's tuned towards the code used in the presentation and nowhere near usable for general D code. I tested it on some of my code and right now it highlights the "in" in "main" as a keyword…

The file also has a little presentation system build in. Press "p" to enable it and arrow down do fade in the next item. However it only really fits if you're looking at the page in full screen mode in Opera (no other browsers support the "projection" mode yet).

You can also take a look at the video of the talk but it's in German. In the first part a friend of mine introduces D and after that I'm showing some more features of the language. Be aware that the video does not work in Opera right now (they broke something in 10.60). There is a link to the second part of the talk:


http://events.mi.hdm-stuttgart.de/2010-04-13-d-einf%C3%BChrung#der-coole-stoff

While the JS syntax highlighter was abandoned I created a language highlighter for GEdit (a Linux text editor). I wasn't happy with the provided one so I made a new one based on the D language specification. If someone here uses GEdit (or an editor that uses the GTKSourceView2 widget) you can give it a try:


http://svn.arkanis.de/projects/tools/gedit_config/trunk/config/langs/d.lang

https://svn.arkanis.de/projects/tools/gedit_config/trunk/config/styles/doblivion.xml
  https://svn.arkanis.de/projects/tools/gedit_config/trunk/tests/syntax.d

The first link is the language specification (just a big bunch of reg expressions) and the second is a color scheme I created for it. The third file is just a small test case to see if it works.

It's pretty complete I believe: it even contains asm instructions and differs between function literals and function types (because I wanted them to be shown in a different color). If there is a need I can try to port it to JavaScript.

Happy programming
Stephan

"Stephan Soller" <stephan.soller@helionweb.de> wrote in message news:i8jvip$1ed6$1@digitalmars.com...
> On 07.10.2010 04:26, Nick Sabalausky wrote:
>> "Stephan Soller"<stephan.soller@helionweb.de>  wrote in message news:i8i10k$2a86$1@digitalmars.com...
>>> On 06.10.2010 02:08, Arlo White wrote:
>>>> That's because HTML/CSS is a pretty terrible language for anything beyond simple layouts. It shares more with Word/PDF/PostScript in terms of its purpose and history than it does with real gui layout engines (GTK, QT, etc).
>>>>
>>>
>>> HTML/CSS is primary made for documents not applications.
>>
>> So true. That, combined with HTTP's stateless nature (and the
>> exploit-prone
>> nature of trying to build state on top of it), is why I view "web as a
>> platform" as being little different from using PDF as an application
>> platform. Heck, the PDF spec is so open-ended it could certainly be done.
>>
>
> Never read the PDF spec, but I don't believe that it includes a world wide network of web servers, does it?

Not explicitly as far as I'm aware, but then neither does HTML aside from URLs. And the PDF format does have provisions for files/data of arbitrary types to be embedded into it. So that could be used to embed HTTP URLs, or any other form of network-oriented links, or any other application-related information/instructions/data you want. Then you could build CSS/JS/CGI-like stuff on top of all that. And all of a sudden "PDF-readers" become a really shitty application platform just like what happened with HTML and web browsers.

>
> To be honest I use fixed with designs a lot. Usually I just don't have so much content that I have to use every part of the screen. ;)
>

I've been tempted to do that as well just because controlling resize-flow is such a pain with HTML/CSS as they currently are.

>> For instance, try to make a resizable box with bit-mapped borders that
>> behaves reliably (I've needed to do a lot of that for a client recently).
>> Easy as pie with tables and CSS background images. But with anything else
>> in
>> CSS, I've become convinced it's just not possible.
>>
>
> Actually is pretty easy in CSS. I also had to do it a lot in the past. You just nest as many elements (usually divs) inside each other as you need background images. Then you use one of those divs to create the border for one side: just assign a background image to this side and a proper padding that makes sure only this side is visible. Corners are a bit tricky to do no problem if you make the main container "position: relative" and then position the corner divs with "position: aboslute". However for most of my layouts I found that I didn't need a variable height and therefore 4 divs where sufficient. This method had it's troubles for IE 5 but in IE 6 you shouldn't have much of a problem (maybe one bug, don't remember exactly).
>

Interesting.

> On modern browsers you can simply user border images (as many as you want). This also eliminates the need for semantically stupid HTML elements. However thanks to box-shadow, border-radius and colors with alpha transparency I hardly use graphics programs to design any more. I just do it directly in HTML/CSS with is usually quite a bit comfortable (and faster!).

I usually like to minimize bitmapped stuff on pages too, just because it's simpler, it can still get acceptable results, and I'm no artist ;)  But then when the client has a design they want it to look like and it includes things that can only be done as images, well, then I just don't have the energy or patience to try to talk them out of it - I'll just toss in whatever I need to to make it work, even if that means tables, and be done with it.

On 06/10/2010 15:25, Stephan Soller wrote:
> On 06.10.2010 02:08, Arlo White wrote:
>> That's because HTML/CSS is a pretty terrible language for anything
>> beyond simple layouts. It shares more with Word/PDF/PostScript in terms
>> of its purpose and history than it does with real gui layout engines
>> (GTK, QT, etc).
>>
>
> HTML/CSS is primary made for documents not applications. If you want you
> can simply make every element a block level element and use JavaScript
> for layout. I don't know GTK and QT in depth but then you should have
> about the same level of possibilities as with these layout engines. It
> wouldn't surprise me if GUI frameworks like jQuery UI actually do this.
>

The issue is not with level of possibilites. HTML/CSS has as much possibilities as many GUI toolkits, if not more. (there is really a lot of stuff you can do you HTML/CSS if you figure out how to). The issue is that it's incredibly hard to do that, HTML/CSS is so convoluted. (and I'm talking about proper flowing designs, now pixel-based, fixed-width ones. Those are fairly easy in both HTML and GUI toolkits).

And what do you mean "use JavaScript for layout"? You can't use JavaScript for layout. You can use JavaScript to programmatically manipulate the CSS properties of HTML elements, but you are still using the same HTML rules for layout, so the difficulty is unchanged.

-- 
Bruno Medeiros - Software Engineer

On 07/10/2010 06:09, Nick Sabalausky wrote:
> "Bruno Medeiros"<brunodomedeiros+spam@com.gmail>  wrote in message
> news:i8hl00$1gv0$1@digitalmars.com...
>> I found that:
>> a) I had practically forgotten all the CSS/HTML rules and info that I had
>> "learned" before, because they were so strange, complicated, and
>> *unnatural* that there is now way you remember them unless you work with
>> it on a daily basis.
>
> I've been doing a lot of HTML and such, off and on, almost as far back as
> when Mosaic was still relevant, and I still spend most of my HTML/CSS-dev
> time with at least one browser tab opened to w3schools.com in the
> background.
>
>

Yeah, same here. Google searches for some particular layout property or quirk were also common. I sometimes even tried to read some sections of the HTML spec itself, but whoa, that thing was way hard to understand, even for a spec. Completely impenetrable, it felt like reading tax legislation or something.

-- 
Bruno Medeiros - Software Engineer

On 07.10.2010 11:02, Nick Sabalausky wrote:
> "Stephan Soller"<stephan.soller@helionweb.de>  wrote in message
> news:i8jvip$1ed6$1@digitalmars.com...
>> On 07.10.2010 04:26, Nick Sabalausky wrote:
>>> "Stephan Soller"<stephan.soller@helionweb.de>   wrote in message
>>> news:i8i10k$2a86$1@digitalmars.com...
>>>> On 06.10.2010 02:08, Arlo White wrote:
>>>>> That's because HTML/CSS is a pretty terrible language for anything
>>>>> beyond simple layouts. It shares more with Word/PDF/PostScript in terms
>>>>> of its purpose and history than it does with real gui layout engines
>>>>> (GTK, QT, etc).
>>>>>
>>>>
>>>> HTML/CSS is primary made for documents not applications.
>>>
>>> So true. That, combined with HTTP's stateless nature (and the
>>> exploit-prone
>>> nature of trying to build state on top of it), is why I view "web as a
>>> platform" as being little different from using PDF as an application
>>> platform. Heck, the PDF spec is so open-ended it could certainly be done.
>>>
>>
>> Never read the PDF spec, but I don't believe that it includes a world wide
>> network of web servers, does it?
>
> Not explicitly as far as I'm aware, but then neither does HTML aside from
> URLs. And the PDF format does have provisions for files/data of arbitrary
> types to be embedded into it. So that could be used to embed HTTP URLs, or
> any other form of network-oriented links, or any other application-related
> information/instructions/data you want. Then you could build CSS/JS/CGI-like
> stuff on top of all that. And all of a sudden "PDF-readers" become a really
> shitty application platform just like what happened with HTML and web
> browsers.
>

Interesting point of view. So PDF basically equals to HTML in that regard. Never thought about it that way but you're probably right. :)

>>
>> To be honest I use fixed with designs a lot. Usually I just don't have so
>> much content that I have to use every part of the screen. ;)
>>
>
> I've been tempted to do that as well just because controlling resize-flow is
> such a pain with HTML/CSS as they currently are.
>
>>> For instance, try to make a resizable box with bit-mapped borders that
>>> behaves reliably (I've needed to do a lot of that for a client recently).
>>> Easy as pie with tables and CSS background images. But with anything else
>>> in
>>> CSS, I've become convinced it's just not possible.
>>>
>>
>> Actually is pretty easy in CSS. I also had to do it a lot in the past. You
>> just nest as many elements (usually divs) inside each other as you need
>> background images. Then you use one of those divs to create the border for
>> one side: just assign a background image to this side and a proper padding
>> that makes sure only this side is visible. Corners are a bit tricky to do
>> no problem if you make the main container "position: relative" and then
>> position the corner divs with "position: aboslute". However for most of my
>> layouts I found that I didn't need a variable height and therefore 4 divs
>> where sufficient. This method had it's troubles for IE 5 but in IE 6 you
>> shouldn't have much of a problem (maybe one bug, don't remember exactly).
>>
>
> Interesting.
>
>> On modern browsers you can simply user border images (as many as you
>> want). This also eliminates the need for semantically stupid HTML
>> elements. However thanks to box-shadow, border-radius and colors with
>> alpha transparency I hardly use graphics programs to design any more. I
>> just do it directly in HTML/CSS with is usually quite a bit comfortable
>> (and faster!).
>
> I usually like to minimize bitmapped stuff on pages too, just because it's
> simpler, it can still get acceptable results, and I'm no artist ;)  But then
> when the client has a design they want it to look like and it includes
> things that can only be done as images, well, then I just don't have the
> energy or patience to try to talk them out of it - I'll just toss in
> whatever I need to to make it work, even if that means tables, and be done
> with it.
>

If I get a design from a client I do that to. I don't use tables but most often a combination of floats and relative/absolute positioning but usually with quite a lot of images in it. Even if they don't have a finished design arguing about it often is a lost cause anyway. However for my own personal project (or in case I have to do the design myself) these new CSS techniques come in quite handy (if the environment allows it...).

I used it for my [personal website][1] and it was quite handy. The only images are the header image, icons and the background gradient. The gradient only because I was to lazy to look up the proper properties and do some cross browser testing (not sure if Opera support gradient yet though).

[1]: http://arkanis.de/

Happy programming
Stephan

On 05/10/2010 13:35, Bruno Medeiros wrote:
> A new web design is nice to have, but frankly, I think much better would
> be a reorganization of the site, at least the D site. I won't go into
> much detail here, but just mention that I think it has too many links,
> and they are not very well organized. I much prefer the
> http://www.d-programming-language.org/ site for example.
>

I've only read now that "the long-term plan is to dedicate d-programming-language.org as the primary D site.", so cool, my complaint is moot. :)


-- 
Bruno Medeiros - Software Engineer