Maybe not and I need to do this in HTML but is there a way to write
if($('.Name1 li').length>2) $('.main').css('k', 'v');
I did this in JS and if I am loading the page for the first time I see a noticeable pop happen. Its not 'bad' but I do 'notice' it.
It would be better if you check this condition on server side (php, ruby, C#, python, whatever) and assign some class then.
CSS is not a programming language, it is not designed to interact with HTML in this way.
Something similar is or will soon be possible using JESS, a framework combining CSS with JavaScript for, umm, "dynamic styling." I haven't looked at it in dept myself yet, but it may be worth a look for people interested in this sorta thing.
Unfortunately you're always going to get this flash of unstyled content whenever you do this kind of class setting with javascript since the JS is loaded after everything else on the page.
Without knowing what specifically you need to achieve, some suggestions would be to use some kind of placeholder CSS on the offending elements (setting a width / height / colour / whatever it is you need) to try to mitigate the effect. You can also try to mitigate it by making sure your page is optimised as much as you possibly can, so give it a run through with yslow and see if there are any speed improvements you can make.
The only other (and best) way would be to use klew's suggestion and insert the class server-side instead of waiting until the DOM has loaded for JS to do its stuff.
Related
I just worked out, by trial-and-error, that IE 7 has an upper limit of 32 stylesheet includes (i.e. tags).
I'm working on the front-end of a very large website, in which we wish to break our CSS into as many separate files as we wish, since this makes developing and debugging much easier.
Performance isn't a concern, as we do compress all these files into a single package prior to deployment.
The problem is on the development side. How can we work with more than 32 stylesheets if IE 7 has an upper limit of 32?
Is there any means of hacking around this?
I'm trying to come up with solutions, but it seems that even if I loaded the stylesheets via Ajax, I'd still be writing out tags, which would still count towards the 32-stylesheet limit.
Is this the case? Am I stuck with the 32-file limit or is there a way around it?
NOTE: I'm asking for a client-side solution to this. Obviousy a server-side solution isn't necessary as we already have a compression system in place. I just don't want to have to do a re-compress every time I make one little CSS change that I want to test.
Don't support IE7.
To avoid confusion: I'm not seriously suggesting this as a real solution.
Create CSS files on the server side and merge all files that are needed for this certain page.
If you are using Apache or Lighttp consider using mod_concat
Write your stylesheet into an existing style block with JavaScript using the cssText property, like this:
document.styleSheets[0].cssText += ourCss;
More info here:
https://bushrobot.blogspot.com/2012/06/getting-around-31-stylesheet-limit-in.html
At my last company we solved this by mashing all the CSS into one big document and inserting a URL in the web page that referenced that one-shot document. This was all done on-the-fly, just before returning the page to the client (we had a bunch of stuff going on behind the scenes that generated dynamic CSS).
You might be able to get your web server to do something similar, depending on your setup, otherwise it sounds like you're stuck with only 32 files.
Or you could just not support IE7 ;)
Is there any problem with using jquery layout plugin (there are several) to layout a page as opposed to using CSS and fixing browser compatibility issues myself?
Another problem is that the page has to fully load and download the javascript, then get rendered. This will slow down the page significantly.
The most obvious problem is that any visitor to the page using a browser with JavaScript turned off will not get the layout. If you're willing to turn away from those people, that may not be a blocking factor for you.
There can also be performance issues, delays on resizing the browser window, that sort of thing.
I'm not saying don't do it; if it's appropriate for your target audience. But look to see if you can avoid it or at least gracefully degrade if JavaScript isn't enabled. (Turn off JavaScript and come here to SO, for instance; still very usable in a read-only way.)
If doing this, continue to be sure to mark up your content in the main page (rather than only adding it dynamically) and use the most semantic markup you can, to improve your search-ability.
When your layout doesn't behave for whatever reason (and that will happen), will you be able to understand the code behind the JQuery plugin to fix it?
Invest in yourself and learn CSS properly, it's not hard, it doesn't take long and it will equip you for the future, don't just rely on plugins. Now I'm not saying never use a plug-in, but this to me seems inappropriate use
I tend to take the academic approach all too often and adhere to strict principles in my development when the reality is that I could have finished the project sooner had I been a little less cautious. I'm looking to find the right amount of practicality.
I want to take the "Zen" approach to designing a site which (in my words) says "Use HTML strictly for content structure, and let the CSS magic do the rest". How practical is this in reality? One of the issues I run into is that I want to develop (make functional) the site first, then come back in and design it later. I know structure-wise how I want the site to flow, but I haven't even begun playing with the CSS layout, graphics, or any of the other designy stuff. What is the right approach here?
It's absolutely practical, and provides infinite benefit. In fact it's exactly what CSS and the separation of content and layout is designed for.
The right approach given the above, is to let different teams get on with the different tasks at hand. That requires (perhaps) an initial graphic design which can be quite rough, and a documented and collaboratively agreed set of naming conventions for things like "#viewport", ".user" etc..
The markup team will usually be backend driven and will usually lead the design team slightly, but they should and must remain flexible enough to change markup where required, or put that in the control of the designers.
This last is just my $.02, but where one person is both roles, again I think you lead yourself with the markup/backend first and then iteratively go to a design stage, then markup, then design, as required.
The approach you want to follow is the right one. Just two things:
If you use a validator for css or html, don't pretend that all your html or css pass the test. Obviously the ideal goal is that everything validates, but at a first stage I think is better not spend a lot of time in validation issues. And remember that no one validator is perfect, and the good way to use it at the beginning is to guide you in the right direction and avoid big mistakes (i.e. put the same id twice in one page, or put block elements inside inline ones...). Then, when the application is at a good stage, you can make your css and html perfect and valid.
Don't design the interface at the end. I think that the interface of the application can give you good directions in how develop your back-end too. So, at your place, I would design the interface first, with html and css, and then I'd start to add functionality to it.
(Sorry for my english, spelling corrections are welcome.)
It can be very practical and you will be suprised how clean your HTML looks. I like using a CSS reset file to help get started, I personally like the YUI reset. Another Zen item to consider is the use of unobtrusive JavaScript. This further separates the different layers of your code. JavaScript libraries, like jquery, prototype and dojo can help with this.
It can be done, and I think your site (and your web design skills, not least) will be much better for it. But it also has a certain learning curve. It requires a more thorough understanding of the XHTML/CSS specs than many people have.
Making sure your HTML can be validated is just the beginning.
Oh, and make sure all browsers run in strict mode when rendering the page.
Of course, you will require workarounds for IE support, but that can be done with several methods.
First, IE supports conditional comments, allowing you to include special CSS stylesheets just to fix IE bugs, which should get you most of the way, without affecting your compliant standard-version of the page.
For some things, you may need a bit of javascript as well, but it shouldn't be necessary for most common functionality.
There are reasons explained in http://www.webdevout.net/articles/beware-of-xhtml against using XHTML today. To summarize, XHTML is not supported unless you serve it as such and if you target older browsers (any IE version is old considering most of its features are implemented when they were still immature and not changed substantially for a while) you have no choice but serve it as HTML.
Unless you don't require features that being XML provides (like SVG, MathML), stick with HTML. You won't have any serious advantage over HTML, be any more semantic, have better CSS support (even less). But you get wider compatibility and your layout will be more predictable (for example table cells can inherit from first cell in the row in HTML, no such thing in XML, not even sure XHTML has any exceptions somewhere).
Validators won't help writing XHTML any more than HTML. Even annoy, if you use a strict one, leaving you wondering what is all the fuss about / in the br tag if you lie and say it is HTML. (Firefox view source shows it bright red if you serve XHTML as HTML). I am sure you can find more examples.
Sure, you can do that, but be prepared that it WILL NOT render under IE. On a recent web project, the majority of our front-end defects were fixing stuff in IE that already worked fine in Firefox. Maybe this will change in IE8, but I doubt it. In some cases we even had to write some javascript that would be executed on IE only to work around things that couldn't be done with just CSS.
while it sounds good in theory you cant create the layout for a site 100% with css. You still need to use some markup so that you have something to apply the css to. That said, you can come fairly close to ideal using this method. I'm constantly amazed at how little markup a true css guru actually requires.
closer the "zen" approach that you are really looking for is xslt. it works by your app generating xml data and then the xslt transforms that xml into html/css. this requires learning xslt and adds another layer of complication to the process of generating a page, but adds the separation you are looking for. In an ideal world the theory is that a programmer only has to worry about generating xml data and then a designer can generate the visuals using that data, however it rarely works that way as xslt is more technical than most designers can handle. Most of the time the programmer ends up generating the xslt which somewhat defeats the purpose.
One approach that works for me is to structure the HTML first, then add some minimal CSS in a tag in the same file (just enough to create the right layout etc). Then once you're happy with the structure, you can pull the CSS out into separate files and / or completely rework the CSS. This strikes the right balance for me - it's still a lightweight process, but it avoids the potential headache of finding and replacing inline CSS.
In theoria yes, in practice, browser differences may force you to add a bit of javascript to deal with the differences.
Now... Benefits of something is different from practicality of doing it. Are you guys forgetting IE or even the pain-in-the-whatever client who wants the impossible done?
I am tempted to say you have to make some exception to the strict DTD that you are using to make it work in a reasonable set of browsers and please your stakeholder for the website/web-app.
I am a standards freak and no one would be more happy than me if it was possible to build a website that doesn't violate even 1 DTD rule. But after 4 years, I just haven't been able to do it for practical purposes.
Sure if I am the one coming up with the requirements for the website I am going to develop, it might be possible, but I have to bend the business rules to accommodate that. Believe me, that's the only way it is possible.
When does it become unavoidable and when would you want to choose JavaScript over server side when you have a choice?
When you need to change something on your page without reloading it.
Designer perspective:
When you want to give more interactivity to your web page
When you want to load stuff without reloading (i.e.: ajax for example)
When you shouldn't use:
When You don't want to spend 1000 hours in pointless tries to disable the back arrow of your browser :)
Google maps would not have been possible without JavaScript. At least not in the form we know (and love) it today. So, depending on your ambition (and requirements) clearly: sometimes JavaScript is unavoidable, even though there exist technologies that take another approach that might have worked equally well (Java Applets, RIA technologies, etc).
If I had the choice I would probably chose JavaScript over a server-side implementation for a large number of applications, but then again, it is not a black or white picture. The server will remain important for web applications for a very long time to come.
Yes, you do. Now take out your textbook and turn to Chapter One. ;)
Honestly, though, to answer your question, I don't think it's ever "unavoidable," no; you can always code for the absence of JavaScript. (Indeed, usability best practices dictate you at least try to "gracefully degrade" the user experience for browsers that don't support it, or for users who choose not to.) In the beginning, of course, there was no JavaScript -- but there was still the Web. It just, well, kinda sucked.
There's no simple answer, but if you absolutely must have one, the most straight-ahead one I can think of is to use JavaScript to improve the user experience. Secondarily, use it to shift the workload from your server toward the browser (Hello, Ajax!) -- validation, state, etc. Those are two big reasons, broadly stated, IMO.
At a stretch, you could do everything via server-side programming. Some things will be painfully slow and difficult to pull off right, but it is possible. If you want to see something clever done with nothing more than CSS, try out the search feature on lxr.mozilla.org with scripting disabled.
Practically though, the best places to use javascript are where it'd otherwise disrupt the flow of what the user's doing - the AJAXy things on here are all pretty good examples, as is the realtime preview (everyone should have one of these!)
If it provides significant benefit, then it's completely fine to use it. But please, don't make it required unless the server-only equivalent is needlessly complicated.
I never want to choose JavaScript, but it becomes unavoidable when clients want a decent web app. JavaScript has the unique feature of low latency feedback in a browser - server side code doesn't.
Also, there are a (rather limited) number of times when it's actually easier to bust out some JQuery for formatting rather than dealing with ASP.NET's event model to manipulate client elements. But, I'd say those are relatively few.
If you are looking for a responsive UI and want to avoid JavaScript, consider some of the RIA technologies such as Flex, Silverlight or JavaFX. I've been developing with Flex since v1.5 and find it very capable and productive. Silverlight is getting significantly better with each release, too.
GWT is a nice system that compiles java code into javascript which becomes kind of like a "Machine language" for the browser--you never have to consider it.
I believe most google apps are written using GWT. It's pretty slick.
All your source code is pretty much straight Java using a library somewhat like Swing.
JavaScript is not a necessity but, coupled with the DOM API, it provides a very useful medium for gradually improving the user experience of your site. Obviously the extent to which this is true is dependent on how well you execute these enhancements, don't just use JavaScript for the sake of it; it's a design decision, and should not be taken lightly.
Sharing the load between client and server.
Try to keep it natural. Use it to enhance little things, do not built your whole application on JS.
A good way to measure the breadth of your skills is when "Do I have to use ..." starts disappearing from your conversation. Hopefully you get to the point where a language is just a language, and you develop a feel for what the right tool is for the job, and can use it as comfortably as any other language.
If it's any consolation, there's increasing evidence that there's enough conventional wisdom and available toolsets that developers are increasingly preferring javascript. I personally like it for its conciseness and easy exensibility - once you get to know it.
You don't have to.
But if you want to provide UI extras like autocomplete, drag and drop, richer form entry fields, etc.…, Javascript is your only answer.
Of course you can abstract that Javascript generation out to the server side but you'd still be tussling with Javascript, albeit via programmatic code generation.
When you create a Rich Internet Application which gets loaded into a browser and which communicate to a Web Server with an Open API (like SOAP, JSON etc)
"Javascript over server side " JavaScript is client side, not server side.
You would still need to run server side stuff to get the data from the server. Javascript just gives you more control on how the client receives the data from the server.
JavaScript is unavoidable when you want a certain dynamic feature on your website which is not supported by default.
Dynamic feature
- without JavaScript: you can use CSS to change background of an element when the mouse is over the element. You can do the same thing with using JavaScript.
- Only in JavaScript: When you click the element with your mouse, the element disappears. Don't think it is possible in CSS(maybe you be able to use :active in CSS on some elements. Never tested it myself).
Has anybody experience in building a custom style in Qt? What I have in my mind is a complete new style that affects all kind of widgets. I have seen some examples in the web for a custom combo box. But I have no idea how much time and code it takes to build a "complete" new custom style ... maybe someone can give me a hint.
We think of using Qt 4.3 (or even newer) ...
Check out the Stylesheets facility in Qt 4. While it's still a hassle, it's way easier than doing a full-on custom style. You can just adjust one visual facet at a time and try it out.
It pays attention to inheritance. So if you style the font in QWidget, then every visual widget will also use that font. And so on.
I have developed a "new" style that changed the appearance of much of an application. It did take some time, and quite a bit of experimentation. I also derived my style from the generic windows style, to allow it to handle some of the stuff I didn't want to mess with. All told, I think it took me a week to get most of what I wanted, with practically no prior exposure to the styles.
In order to actually develop one, I would get into the source for their styles example, which has a "wood" style. I put my own style in place of the example style, and started changing things while using the example program to check how it looked. Depending on how you are developing it, you might want to have a configuration file so you can easily change some of the values without recompiling.
You might want to look at existing styles. You can find quite a few of them on kde-look.org, in the Styles / 4.0 section.
We've done it in the past (in Qt 3), and it's extremely time-consuming. We had a lot of problems with flickering, redraws not working the way we expected, sluggish behavior, bugs in the Qt implementation. It a lot less straight-forward than it seems, and there's little support or user experience too. Unless you need something really particular (as we did), I'd say it's not worth the trouble.
Other frameworks are supposed to make it easier (some Java-based?), but I don't have first hand experience.
If you don't need to radically change the widget style, you might want to try using widget style sheets:
http://doc.qt.digia.com/4.4/stylesheet.html