Re: New web newsreader - requesting participation
Quite some impressive stuff. Actually I'm somewhat blown away. Looks like I'm going to try GCI with D in the near future. :) The compile run functionality looks very solid. Sorry for assuming bad security. setrlimit, extra VM, internal and external firewalls… looks like it's as solid as it can get. Happy programming Stephan On 31.01.2011 18:03, Adam Ruppe wrote: Stephan Soller wrote: Cache invalidation How do you handle this right now? I don't. My program assumes that once it has a message, it never needs to look to the server for it again. (This is probably because of my own experience with mailing lists - I use the mailing list interface to the newsgroup for reading. With them, once the email is sent, it isn't going to change. I just assumed the newsgroup worked the same way...) D website I really like the layout. The credit for that goes to Christopher Bergqvist. See the thread Suggestion: New D front page in the main newsgroup. He posted a png outlining his idea and I just ran with it :) The compile and run button is a bit of a security risk. I was able to read the /etc/passwd file for example. Yeah, but that's normal on a multi user linux system. It doesn't really break anything. But, I moved the compile and run program to a separate VM to further limit it. If you read that entire filesystem, it doesn't really matter - it's an out of the box Slackware install. There's nothing sensitive or private on it at all. (Like it's domain name says, it is completely expendable info!) Denial of service attacks (e.g. endless loops) might still be a problem though. I think this is solved with my use of setrlimit. If a process eats more than 5 seconds of CPU time, the operating system kills it. The limits are also set to 16 MB of RAM, 16 kb files, 3 forks, and a bunch of other things. (This might be interesting to test some programs - it will actually get out of memory exceptions pretty easily!) Write access is also limited to a single directory, in addition to that individual size limit. Filling up the disk shouldn't be possible. The operating system firewall prevents most network activity, incoming and outgoing. You can play with sockets, but only if they are working with localhost, and even then, they aren't allowed to access the ssh port. Running a spam bot off it is impossible. More than this, the VM is also limited. I set its memory and CPU limits to about 1/5 the resources of the physical server. So if you did manage to get root and max out your program, it won't have a significant impact on the other things running with it (all low traffic websites). An external firewall serves as layer 2 to protect against spambots. Finally, I did a VM snapshot after setting it up. I'm considering running a scheduled script on my computer to blank and reset that VM every night. Then, if you got root and worked around my other restrictions, it'd be a temporary victory anyway, just until I revert the snapshot again. All in all, I think I have a pretty safe setup. If I'm proven wrong, plan B is to use the ideone API instead. If you only display mails in the announcements which do not have a References header you will only get mails that started a new topic. This will filter out replies. Yes, that's what I wanted. The idea is to show a feed of new things coming out, rather than new replies on old ideas. This way, the homepage shows the most variety. Happy programming Thanks! If I have any questions, I'll be sure to ask. I've gotta get back to my real work soon though (stupid Monday) so finishing this will probably have to wait until next weekend.
Re: New home page
On 14.10.2010 13:03, Bruno Medeiros wrote: On 14/10/2010 09:09, Stephan Soller wrote: There is no confusion, I know the position property does not influence how large an element is. I don't care how big or small the inner div is, I just want it to be contained in the parent div. I just mentioned the 'position' property because if position is 'fixed', it does make sense for that div not to be considered as contained in the parent div. But not so for other values of position (at least for the default one). Sorry, look like I got confused then. :) I'm still not sure if I understand your point correctly. Do you mean that it's inconsistent that some positioning models take the element out of the document flow? Not exactly. My problem is that when an element is taken out of the flow (such as with float:left), it means the element no longer needs to be contained in the parent div. I think that model is very unhelpful. Although I'm no expert in HTML coding, I would venture that in at least 90% of the cases that's what you want (for the element to be contained in the parent, if its position is not 'fixed'). Otherwise this brings up several problems: it messes up the layout of the elements right after the parent div. Or it messes up the area for the background/border colors of the parent div. However if a clearer div works without additional problems, I'm probably happy with that, even if its more verbose. In the context of using floats for multi column layout I agree with you. It just doesn't make sense for the parent element to not contain any floating child elements. I looked in the CSS 2.1 spec to figure out why they defined it this way and the third example in the [section about floats][1] makes it pretty clear. Basically if you float an image in a paragraph you want the next paragraph to float around it, too. If you don't want it set the clear property of the next element (e.g. headlines). Therefore the cross border of parent box default is a good choice in such situations. When using floats for layout I would rather like the default to be that floats are contained in their parent boxes. But that is not what floats were made for so the decision is ok IMHO. [1]: http://www.w3.org/TR/CSS21/visuren.html#floats But all this does not change the fact that using floats for column layouts is still nothing else than a workaround for the missing column layout model in the early days. For many page layouts this actually isn't needed but especially people used to use tables for layouts often try to use this technique because it mimics tables more or less. With CSS tables you don't have to use floats any more since you have all the power of tables in CSS now (with less markup in most cases). These however only work with IE 8 or newer (I'm not sure if not already in IE 7) and I don't know about FF 2. If you have to make pages that work in IE 6 and 7 you still have to use floats though. Well I would say some sort of column layout model (if understood your term correctly) is pretty essential. You need something like that, or something that can do the same job nearly as easily. So are you saying its ok to use CSS tables now? (disregarding the issue with old browsers) Because when I first learned about CSS and div layouts, the mantra was tables are evil, don't use tables. I also heard/read that a lot when learning CSS. Using table _elements_ for layout is bad stuff since the table element in HTML indicates tabular data. If you use it for layout the abstract content (or data) of the page gets totally screwed up just for it to look right. However the layout rules of tables are quite useful and so they found their way into CSS. If you can properly separate data from presentation you can use whatever layout rules you want. ;) Basically don't use table _data_ to push elements around in HTML. Using table layout rules in CSS is ok since it does not interfere with the data of the page. Ok, so it is as I thought, is is still wrong/unrecommended to use tables for layout. The recommended way to do column layouts is still with divs, right? By column layouts I don't mean tables, but stuff like a sidebar of any kind (the typical two or tree column layout). Yes, in HTML4 and XHTML 1 you would use div elements for each column. I actually don't like that very much because it usually ends with a lot of div elements that don't add any useful information to the document. It's still better than tables though because table elements have a meaning that isn't met. But that's a problem of these two HTML versions (they lack structural block level elements). HTML5 adds more meaningful elements for that purpose (section, aside, header, footer, …) but that's a different story. Happy programming Stephan
Re: New home page
On 13.10.2010 14:30, Bruno Medeiros wrote: On 10/10/2010 15:23, Stephan Soller wrote: On 07.10.2010 11:41, Bruno Medeiros wrote: 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). It does not feel convoluted to me but I have learned HTML/CSS gradually as they evolved. Therefore I might not be able to properly see how it looks from the distance if someone doesn't know the details. To me it looks well structured (block vs. inline elements, different distinct layout models, typography, etc.). There sure a some parts that deserve a little cleanup and simplification but I can't think of any right now. I'm just curious about your point of view. What parts of CSS look convoluted to you? The layout rules. I don't remember the details, because again I've forgotten the rules and most of what I learned then. There is only issue I can remember on the top of my head: * If you have two nested divs, and the inner div has a position value other than fixed, it is not true that the inner div is visually contained on the other div! That makes no sense to me. You have to add some properties to the outer div (such as overflow:hidden) to make it so, but it usually these properties have side-effects that are adverse to other aspects of the layout. I think you are confusing two things. The position property does not influence how large an element is (it contains all it's normal content). The value static is the default value and does nothing at all (the box is not positioned, that's what you probably meant with fixed). absolute lets you position the box at arbitrary coordinates but also takes it out of the flow. That is all elements after it ignore absolute positioned boxes. This effectively allows you to layer stuff like you want. There are some more values (relative and fixed) but this isn't a CSS lesson. The behavior you describe is a problem of the float layout model. If you float an element left or right it is taken out of the normal document flow but all following content flows around it. This was defined for pictures or figure in texts. You can then use the clear property on the next paragraph to stop it from flowing around the picture. Since early CSS had no proper layout model for multiple variable height columns (like tables are by definition) man people used the float layout model to emulate multiple columns. The problem with this is that the floated columns are taken out of the normal document flow. Therefore the parent element does not contain them and usually collapses to zero height. To avoid this you can either add a clearer after the columns or use the overflow trick (any value other than visible will do) which will make the parent box containing all it's floated child elements. This works in IE 6 and does not need an extra element. Therefore it's the most used technique now. But all this does not change the fact that using floats for column layouts is still nothing else than a workaround for the missing column layout model in the early days. For many page layouts this actually isn't needed but especially people used to use tables for layouts often try to use this technique because it mimics tables more or less. With CSS tables you don't have to use floats any more since you have all the power of tables in CSS now (with less markup in most cases). These however only work with IE 8 or newer (I'm not sure if not already in IE 7) and I don't know about FF 2. If you have to make pages that work in IE 6 and 7 you still have to use floats though. 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. You're right. At the end HTML/CSS simply is the interface to tell the browser about the structure and appearance of your document. However you can
Re: New home page
On 10.10.2010 22:42, Nick Sabalausky wrote: Stephan Sollerstephan.sol...@helionweb.de wrote in message news:i8sh5u$2ij...@digitalmars.com... On 07.10.2010 23:59, Nick Sabalausky wrote: Stephan Sollerstephan.sol...@helionweb.de wrote in message news:i8kmuc$15...@digitalmars.com... On 07.10.2010 14:56, Nick Sabalausky wrote: Stephan Sollerstephan.sol...@helionweb.dewrote in message news:i8k8k9$230...@digitalmars.com... [1]: http://arkanis.de/ Not to complain, just FYI, this is what that page looks like for me: http://www.semitwist.com/download/arkanis1.png http://www.semitwist.com/download/arkanis2.png http://www.semitwist.com/download/arkanis3.png Interestingly, if I turn JS on, than it'll look a lot better *until* it finishes loading, at which point it goes back to looking just like those screenshots. Thanks for the screenshots. May I ask which version of Firefox (if I see that correctly) your're using v2.0.0.20 Which actually kinda surprises me because I could have sworn I was on a much later version of the 2.x line. I *know* there was a period where it kept updating itself seemingly all the time (which got quite irritating when I just wanted to go to a particular URL). But I guess that must have been the only 2.x version I was able to find after giving up on FF3. And IIRC, the built-in update won't let me update to anything less than FF3. And yea, I know FF2 is really old, but I tried 3.0 and 3.5 and the JS was only marginally faster, it doesn't seem to fix any of the rendering bugs I've come across in FF2 (I have 3.5 on my Linux box, just for site testing), and every other change they made I hated and downloaded extentions to undo...until I realized there was no extention to un-unify the unified forward/back buttons (which I had thought was a good idea when IE7 came out -- until I actually used IE7), and realized the only winestripe-like things for FF3 weren't nearly as good as the real winestripe. So I figured Why bog it down with even *more* addons just to turn it into a half-baked FF2, when I can just use the real FF2? YouTube bitches to me about it, but well, fuck YouTube; never liked having over-compressed videos pre-embedded into a web-based player anyway. Maybe you should consider looking into some other browsers? Opera, Chrome and other Gecko based browsers might give you a better experience that the newer Firefox versions. This is the reason why there are different browsers after all. - Safari is ruled out because it's a blurry mess (all for the sake of making it look more like the printed version? WTF?) and forces useless background processes, has zero respect for my system's look-and-feel, and has no Adblock Plus, NoScript, or BetterPrivacy (Three FF add-ons that provide functionality that, for me, are absolutely 100% essential). - IE7+ is out because it has no Adblock Plus, NoScript, or BetterPrivacy, and I don't like the unified forward/back buttons. - Iron is out because I *hate* absolutely everything about it's UI, and it doesn't have NoScript (I've heard it has AdBlock Plus, but I didn't see it when I first looked so I don't know). Also, configurability seems to be practically non-existent compared to FF. - Chrome is out because of all the reasons for which Iron was created in the first place. I won't even allow Chrome (or Safari) on my computer at all. - Opera is ruled out because it costs money and every time I tried the demos it seemed to combine the worst aspects of all the other browsers, plus had by far the most rendering problems. - And everything else like IE6-, Netscape, WebTV, Lynx, etc are all ruled out for obvious reasons. Adblock Plus, NoScript and BetterPrivacy are a combination that's hard to find in other browsers. I suppose you have to do some manual configuration to get that done. Many browsers today compress the UI in order to free more horizontal space for the websites. There is an ongoing development towards wider displays that shrink in height and the new browser UIs are a logical counter development to that. In Opera however it's just the default configuration and with a few clicks you can bring every toolbar back (and add or remove buttons, etc.). Never found a way to revert that in Firefox or Chrome but I haven't searched every about:config option. Regarding configuration Opera is on pair with Firefox if not even more flexible, therefore they don't have extensions. Opera giving the most rendering bugs is actually a funny story. They had the most advanced quirks mode (IE 5 compatibility mode). It changed quite a bit in the rendering of websites and was very close to IE 5 (I really doubt they had fun programming this). However many developers didn't know how to trigger standard compliant mode back then (these strange DTDs...) and forced Opera (and IE 6 and Firefox) into quirks mode. But since Firefox looked more or less the same in quirks mode people of course regarded the Opera and IE rendering as
Re: New home page
On 11.10.2010 13:01, Nick Sabalausky wrote: Stephan Sollerstephan.sol...@helionweb.de wrote in message news:i8ufto$17d...@digitalmars.com... Adblock Plus, NoScript and BetterPrivacy are a combination that's hard to find in other browsers. Yup. And that's speaks very poorly for the overall state of web browsers. It's amazing that with so many offerings there's none that are actually any good. Not only browsers but more general the understanding of privacy on the Internet among its users. Many browsers today compress the UI in order to free more horizontal space for the websites. There is an ongoing development towards wider displays that shrink in height Which, of course, is an absolutely rediculous trend that's been created almost entirely on faulty notions, but that's a whole other rant... I absolutely agree on that. and the new browser UIs are a logical counter development to that. In Opera however it's just the default configuration and with a few clicks you can bring every toolbar back (and add or remove buttons, etc.). Never found a way to revert that in Firefox or Chrome but I haven't searched every about:config option. Yea, about:config is truly awful. I consider any setting that's only in there to be non-existant (unless I just happend to come across someone mentioning a specific one, as was the case with turning off animating images and favicons (I turned off favicons only because FF's no animate setting doesn't work for favicons)). ps.: Opera is free since over 5 years, so you might want to take a look since much has changed since then. Just gave the latest version a try (turns out the last I tried was 9.x and was about three years old, although I know that wasn't the first time I had tried it). I haven't spent much time with it yet, but my initial impressions: When it first started, first thing I did was get rid of that awful menu button. Then I balked at how incredibly ugly the real menu and tabs are. I went to find a way to disable themes, but then discovered that it was *already* on the supposed Windows Native Skin, which is quite obviously anything but. Looks exactly like GTK to me. There's the tell-tale GTK Rediculously Excessive Padding, and the almost-equally tell-tale Invisible text for light-on-dark users (black-on-black). And then as if that wasn't bad enough, there's this really amateur-ish hover/pressed highlight on the top-level menu items, which 1. is obviously non-native since native has no hover effect and *I* have my selection color set to blue, but this uses white instead, and 2. results in even *more* invisi-text (white-on-white). The tabs don't even try to be tabs at all, just GTK buttons acting like tabs. And the menus appear with a fade-in that's clearly *intended* to look like the subtle fade-in native stuff uses, except unlike the native apps they're jarringly...well, choppy is the only way I can think to describe it. And there seems to be some weird drawing-conflict between them and the tabs during that fade-in. It looks really really bad, and disabling effects doesn't get rid of it. The whole UI is just a complete amateur job (which is pretty much what I remember from every other time I tried it, now that I think of it). Haven't tried any actual pages or any sort of AdBlock/NoScript/BetterPrivacy sort of functionality yet. Ok, I'll stop recommending browsers then. Maybe you should just grab WebKit or Gecko and build your own UI around it. This will also give you (almost) all the privacy control you want. ;) Just to give the Opera guys some credit: technically their UI is pretty well done and fast (it's based on Qt and they skipped hardware acceleration for this release because it wasn't the bottleneck). The default design is a different story but I personally think they hit what the masses currently would call a nice design. Happy programming Stephan
Re: New home page
On 07.10.2010 23:59, Nick Sabalausky wrote: Stephan Sollerstephan.sol...@helionweb.de wrote in message news:i8kmuc$15...@digitalmars.com... On 07.10.2010 14:56, Nick Sabalausky wrote: Stephan Sollerstephan.sol...@helionweb.de wrote in message news:i8k8k9$230...@digitalmars.com... [1]: http://arkanis.de/ Not to complain, just FYI, this is what that page looks like for me: http://www.semitwist.com/download/arkanis1.png http://www.semitwist.com/download/arkanis2.png http://www.semitwist.com/download/arkanis3.png Interestingly, if I turn JS on, than it'll look a lot better *until* it finishes loading, at which point it goes back to looking just like those screenshots. Thanks for the screenshots. May I ask which version of Firefox (if I see that correctly) your're using v2.0.0.20 Which actually kinda surprises me because I could have sworn I was on a much later version of the 2.x line. I *know* there was a period where it kept updating itself seemingly all the time (which got quite irritating when I just wanted to go to a particular URL). But I guess that must have been the only 2.x version I was able to find after giving up on FF3. And IIRC, the built-in update won't let me update to anything less than FF3. And yea, I know FF2 is really old, but I tried 3.0 and 3.5 and the JS was only marginally faster, it doesn't seem to fix any of the rendering bugs I've come across in FF2 (I have 3.5 on my Linux box, just for site testing), and every other change they made I hated and downloaded extentions to undo...until I realized there was no extention to un-unify the unified forward/back buttons (which I had thought was a good idea when IE7 came out -- until I actually used IE7), and realized the only winestripe-like things for FF3 weren't nearly as good as the real winestripe. So I figured Why bog it down with even *more* addons just to turn it into a half-baked FF2, when I can just use the real FF2? YouTube bitches to me about it, but well, fuck YouTube; never liked having over-compressed videos pre-embedded into a web-based player anyway. Maybe you should consider looking into some other browsers? Opera, Chrome and other Gecko based browsers might give you a better experience that the newer Firefox versions. This is the reason why there are different browsers after all. Staying with FF2 for to long might really hurt your browsing experience since quite a bunch of functionality was added to the browsers itself lately. And trust me, it's really way easier to use the new stuff than all the old workarounds (e.g. webfonts, svg, css based animations, transparency, dropshadows, video, and the list goes on...). I really expect many people to use this stuff in the near future, not only because it's cool but mainly because it's so much easier than the old stuff. I've seen people holding on to Netscape 4 because they didn't like the newer versions. They could endure a surprising amount of totally broken pages but the internet wasn't fun for them. Fortunately we have a lot more alternatives today. :) The JS stuff is quite interesting since the page actually does not use JS at all. The only situation where JS should actually be involved is for IE (because you need to introduce unknown elements to IE before using them). I'm not aware that any version of Firefox interprets IE conditional comments (although there was talk about it once) so this behavior is somewhat concerning. Don't worry. Turns out it was just a quirk caused by one of the million add-ons I have installed to make the web bearable. When I disabled all of them, the behavior and results with JS on were exactly the same as with JS off. However this page uses quite new and still in progress browser stuff (HTML5, CSS3) so it'll give old browsers a very hard time. It's more like a showcase for the new stuff. I see, that explains it. Personally, I'll have no interest in CSS3 unless MS decides to backport IE9 to XP. I hate Win7 and refuse to let XP die (Granted, Win7's not quite as bad as Vista, but it's close). Take a look at [this screenshot][1] to see how it's supposed to look like. It was made with font antialiasing on a standard TFT but the text might look a bit awkward on CRTs or TFTs with a different subpixel layout (usually the OS takes care of that when rendering text). There's also the [design prototype][2] which does not use the new techniques. It should work on your browser (at least most stuff, I never IEified it nor did extensive cross browser testing since it's only a prototype). [1]: http://arkanis.de/projects/arkanis-development-v3/ubuntu.png [2]: http://arkanis.de/weblog/2008-05-25-modern-ambience-design-prototype/ And finally there's also the [old design][3] which works in IE 5.5, 6 and 7 (ditched 4, 5, and 5.01 and I'm not sure about 8). It took about two weeks to make it work in IE 5.5 and 6 if I remember correctly. [3]: http://arkanis.de/projects/arkanis-development-v2/photo-ambience/ Ahh. Yea,
Re: New home page
On 07.10.2010 11:41, Bruno Medeiros wrote: 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). It does not feel convoluted to me but I have learned HTML/CSS gradually as they evolved. Therefore I might not be able to properly see how it looks from the distance if someone doesn't know the details. To me it looks well structured (block vs. inline elements, different distinct layout models, typography, etc.). There sure a some parts that deserve a little cleanup and simplification but I can't think of any right now. I'm just curious about your point of view. What parts of CSS look convoluted to you? 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. You're right. At the end HTML/CSS simply is the interface to tell the browser about the structure and appearance of your document. However you can make every element a block level element (display: block;) and use absolute positioning. Then each element basically behaves like a window of an window manager and you can use your own algorithms to do the layout by calculating the position and dimensions (top, left, height, width). At that stage you don't have to think about any of the layout models of CSS and you're totally independent of them. Happy programming Stephan
Re: New home page
On 07.10.2010 04:26, Nick Sabalausky wrote: Stephan Sollerstephan.sol...@helionweb.de wrote in message news:i8i10k$2a8...@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
Re: New home page
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
Re: New home page
On 07.10.2010 11:02, Nick Sabalausky wrote: Stephan Sollerstephan.sol...@helionweb.de wrote in message news:i8jvip$1ed...@digitalmars.com... On 07.10.2010 04:26, Nick Sabalausky wrote: Stephan Sollerstephan.sol...@helionweb.de wrote in message news:i8i10k$2a8...@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
Re: New home page
On 07.10.2010 16:23, Lutger wrote: 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! This is a popular javascript syntax highlighter: http://alexgorbatchev.com/SyntaxHighlighter/ I've written a D plugin for it (its trivial and not completely correct): http://github.com/Lutger/d_utils/blob/master/shBrushD.js Thanks for the link! I think I'll use that for my next D stuff. :) When doing a presentation about a programming language I somehow tend to write a small and minimalistic syntax highlighter for it. Balances the odds of content creation vs. programming a bit I guess... Happy programming Stephan
Re: New home page
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. However the way GUI frameworks approach layout isn't very well suited for documents and therefore I'm very happy that they oriented CSS on documents (there were several early drafts and what we know today was just the draft from Howcome Lie). Hardcore HTML/CSS people tout the virtues of separating the content from the presentation. The problem is that HTML has implicit presentation that you often can't override with CSS. There are limits to what you can do with positioning. If I want to rearrange elements in my page I have to change the HTML, I can't do it all on the CSS side. That's not separation of content from presentation! 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. Real separation of the presentation has to happen right at the data layer. But that's server side in most applications. So you run your data through one view abstraction (template language such as Freemarker, PHP, JSP etc), then to HTML, and then polish it with CSS. Oh, and that application runs on an app server that runs in a Java virtual machine that runs in an VMware OS that runs on a real OS that actually accesses real hardware. That's an absurd number of layers... Anyway, to get back to HTML. They'll say use divs not tables because a table represents a distinct concept not a layout element and it has accessibility implications. And yet I you can't layout things with divs in the same way that I can with a table. And even if there are obscure CSS properties that let me, half the user's browsers don't support them. Unfortunately this is true (if half the user's browsers refers to IE 6 and 7). In other browsers however you can do exactly the same as with tables but with significantly less HTML elements (display: table property). Plus the other positioning models allow you to do things that are not possible with HTML. Netscape 4 once supported an layer element which could have been used to do stuff like you can do with position: absolute but the resulting HTML had nothing to do with a document any more. Sometimes I feel like I'm the only one that sees the naked Emperor. People are so excited about the Internet but they don't realize that browsers are just implementing one view language that's 15 years old and really isn't all that great. The beauty of the Internet is the emergent properties that arose from the concept of linking sites. But that's not something that has to be unique to the HTML language itself. And sure there's some cool stuff in HTML5 but a pig's still a pig even when you velcro a TV to its head and a database on its back. -Arlo I have to agree that it's all about linking content that really created the web. It's not unique to HTML (I even saw thinks like that in The mother of all demos form Douglas Engelberth, 1968) but more to HTTP. HTML just happened to be wildly used to create documents on the web. As for HTML5 still being a pig… well I definitely agree at some parts but they already cleaned up a lot. Just because the structure of C once was quite ugly (IMHO) doesn't mean that D is still ugly (since it's based on C). Technologies as well as taste evolve constantly. On 10/04/2010 02:23 PM, Walter Bright wrote: That's what bugs me. Something as straightforward as a 3 column layout shouldn't require tricks for it. Googling it found 3 pages dedicated to explaining this trick (each of them wildly different, of course).
Re: New home page
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. ;)
Re: New home page
On 05.10.2010 04:28, Nick Sabalausky wrote: Walter Brightnewshou...@digitalmars.com wrote in message news:i8d77c$1bf...@digitalmars.com... Stewart Gordon wrote: The layout breaks in anything but the default text zoom. The annoying thing about this is everyone says don't use tables for layout, use CSS. Except that using CSS for layout DOESN'T WORK RELIABLY. With tables, I can get 3 columns that are actually 3 columns, not 3 columns that are a side effect of bugs in CSS. YES!! This is a pet peeve of mine (but then, what isn't? ;) ). I've even been meaning to write up a little article about it. For styling, CSS is, umm, acceptable. But it's crap for layout. And every argument I've seen against using tables for layout has been either extremely minor, questionable/uncited, or just plain bullcrap. Speaking of, if anyone has links to well-regarded why you shouldn't use tables for layout information, please post them. Whenever I get around to doing that little write-up I'd like to try to refute as much as I can. Or be proven wrong before making a bigger ass of myself. Either way :) The point in not using the table _element_ for layout is that HTML should be used to define the _content_ of your page not its appearance. It's all about what kind of data you have at hand: a heading, a list, tabular data, a figure with an image, etc. It says nothing about how the page is supposed to look, it's just the pure content. After defining the content the appearance is setup with CSS. And there table layouts are used pretty often (if not always). If you don't care about older IE versions you can use display: table and companions. Basically these display properties just make elements behave like the corresponding HTML elements (e.g. table-cell maps to the td element). Prior to that CSS only had mechanisms for defining float layouts (the float property) but these can be used for table layout, too. It's not that difficult but it's less flexible. All you need is a container with overflow: hidden. To create columns inside it just set some child elements to fload: left. This will look like this: -- overflow: hidden -- || | -- float: left -- -- float: left -- | | | | | | | | | | | | | | | | | | | | | | - | | | | | | - | || -- This method works quite well, only IE 6 makes some trouble because the floats trigger some bugs (but if you add a few pixels of reserve space it will be all right for IE 6). The main drawback of this method is that the floated boxes are independent of each other, each gets its own height and with. If you want them to have a consistent layout you have to assign fixed widths and highs. There are some workarounds for this (e.g. using a repeating background image on the container) but I suppose I already talked to much about CSS. Basically it's all about separation of content and presentation. It's not always easy (nor always necessary) but if done right you don't have to touch the HTML code for your next redesign (and the search engines are very happy about proper HTML code, too). ps.: I'm usually only reading this newsgroup because I'm somewhat new to D. But I couldn't resist answering about CSS. ;) Happy programming Stephan Soller
Re: New home page
On 05.10.2010 12:24, Nick Sabalausky wrote: Stephan Sollerstephan.sol...@helionweb.de wrote in message news:i8epjv$1d3...@digitalmars.com... (and the search engines are very happy about proper HTML code, too). I've actually come across this point before, that search engines will rank a page that doesn't use tables for layout better than one that does. I can't really argue against that point, but I am really curious. Does anyone have links to any authoritative information on this? I would also like to see solid information on that topic but I'm afraid this statement is very hard to catch. The Google SEO Guide mainly focuses on the title and description of websites as well as headings an links. I suppose more detailed structures and elements (lists, tables, em, code, etc.) are not that important for search engines but for other tools that need to work with the document structure (js scripts, screen readers, semantic analysis, data mining, etc.). Happy programming Stephan
Re: New home page
On 05.10.2010 12:13, Nick Sabalausky wrote: Stephan Sollerstephan.sol...@helionweb.de wrote in message news:i8epjv$1d3...@digitalmars.com... On 05.10.2010 04:28, Nick Sabalausky wrote: Walter Brightnewshou...@digitalmars.com wrote in message news:i8d77c$1bf...@digitalmars.com... Stewart Gordon wrote: The layout breaks in anything but the default text zoom. The annoying thing about this is everyone says don't use tables for layout, use CSS. Except that using CSS for layout DOESN'T WORK RELIABLY. With tables, I can get 3 columns that are actually 3 columns, not 3 columns that are a side effect of bugs in CSS. YES!! This is a pet peeve of mine (but then, what isn't? ;) ). I've even been meaning to write up a little article about it. For styling, CSS is, umm, acceptable. But it's crap for layout. And every argument I've seen against using tables for layout has been either extremely minor, questionable/uncited, or just plain bullcrap. Speaking of, if anyone has links to well-regarded why you shouldn't use tables for layout information, please post them. Whenever I get around to doing that little write-up I'd like to try to refute as much as I can. Or be proven wrong before making a bigger ass of myself. Either way :) The point in not using the table _element_ for layout is that HTML should be used to define the _content_ of your page not its appearance. ... Basically it's all about separation of content and presentation. It's not always easy (nor always necessary) but if done right you don't have to touch the HTML code for your next redesign (and the search engines are very happy about proper HTML code, too). Yea, I do agree in principle. But in my experience, certain realities of CSS complicate the issue. Basically, I've spent enormus amounts of time and energy getting certain layouts to work properly and reliably in CSS. There's been plenty of times I've come across that and eventualy just threw my hands up and said Ok, the heck with purity and ideals, I just need to get it done: So hello tables!. And every single time I've done that everything went smooth from that point on. If CSS could handle layouts as well as tables can, then I would be all for abandoning tables-for-layouts. But CSS just isn't there yet. And I don't see it progressing much. Plus I often find redesigning HTML a lot more straightforward than tweaking typical production-scale CSS (CSS can get real hairy real quick). Not only that, I've recently started doing my sites in a very MVC/rails/django-ish way whenever possible, so for me, the HTML usually *is* just as much part of the view as the CSS anyway. And all I have to do to redesign it is just tweak an html template file. As a bonus, that allows for much more flexibility in my redesigns (and much more easily) than CSS could ever hope to achieve without CSS itself getting a fundamental overhaul. ps.: I'm usually only reading this newsgroup because I'm somewhat new to D. But I couldn't resist answering about CSS. ;) Welcome :) Thanks. :) I have to agree that CSS layout techniques have a somewhat steep learning curve. It's straight forward to use floating boxes for column layouts and bugs in IE still hurt. However it's the same in every language/field (e.g. it was totally new to me to use () ? x : y to get the common type of two expressions). Once you get to know some of the techniques it's way more easy to do stuff in CSS, often just because you have less text to type and everything in one place (a few lines in a CSS file). If CSS could handle layouts as well as tables can, then I would be all for abandoning tables-for-layouts. But CSS just isn't there yet. And I don't see it progressing much. CSS is absolutely ready, IE 6 and 7 are not. As soon as you can assume IE 8 or any decent browser you can use CSS tables. Sitepoints Book [Everything You Know About CSS Is Wrong][1] is a very practical guide to these handy properties. There are also some more experimental column or grid based properties but I haven't seen any of them out in the wild. CSS 3 defines quite some interesting stuff but it's very hard to tell if or when someone can use it. [1]: http://www.sitepoint.com/books/csswrong1/ Plus I often find redesigning HTML a lot more straightforward than tweaking typical production-scale CSS (CSS can get real hairy real quick). Production-scale CSS can get really ugly really fast without a fitting coding style (e.g. I'm almost always defining margin and padding on any layout elements, just to have the actual values available at the same code line). Not only that, I've recently started doing my sites in a very MVC/rails/django-ish way whenever possible, so for me, the HTML usually *is* just as much part of the view as the CSS anyway. And all I have to do to redesign it is just tweak an html template file. As a bonus, that allows for much more flexibility in my redesigns (and much more easily) than CSS could ever hope to achieve
