I'm in the process of selecting an HTML5 template for my web projects. I've been using HTML5 Initiliazr which uses Boilerplate for the last few months but decide to reevaluate the two templates, since I don't like the issues with HTML5 Boilerplate's CSS not being valid against W3 CSS validator (CSS3).
Now my question is, given the fact that both CSS resets also take into account vendor quirknesses, will those resets ever be completely valid or is it impossible to assume such a thing?
I did noticed that HTML5 Reset actually has a few issues less than Boilerplate but that might change in the future. However, I did read Boilerplate's explanation on why each and every style was introduced and what problems it solves, so it kinda makes sense.
So what do you think?
Boilerplate's css uses few hacks like * (*font-size:small;) and some browser specific css rules - if you are really concerned about validation just move the hacky rules out of the main style.css and load them for the browser that needs them only.
You can be either hacky and crossbrowser or valid and degraded. And don't forget that boilerplate also states:
Think there's too much? The HTML5
Boilerplate is delete-key friendly. :)
But if you ask me - its waste of time trying to pass the css validation and still be crossbrowser compatible - if your client demands it and has extra money to pay for the css valid badge (which probably won't generate them any extra income) than go for it, if you personaly are obsessed by having to pass it go for it - otherwise it's nonsense and waste of your time. If you wrote all of the valid css3 rules correctly and used a few vendor specific rules it won't really kill anyone.
Overall Boilerplate is a solid template and perfectly ok to use for every day projects and the problems you are exposing are more of a perfectionist's view on the thing. This would be my 2 cents on this.
Related
Thymeleaf puts a large emphasis on "natural templating", which means that all templates are already valid XHTML files. I always thought that is a great step forward that I can generate fragments in my templates e.g. in JSP I'd write
<tagfile:layout title="MyPageTitle">
<jsp:body>
Main content goes here
</jsp:body>
</tagfile:layout>
My "Layout"-Tagfile contains all the header-tags (title, link to stylesheets,...), the menu and justs inserts title text and body at the right point. I don't need to know anything about stylesheets menus or the like when designing my html fragement.
This is in contrast to the idea of Thymeleaf which encourages me to create full html pages (including a sample menu and all the headers). While the manual of Thymeleaf continues to emphasise how great this is, it never deals with duplication of code concerns:
I have one template that generates a menu and all my other templates (could be many) include a copy&pasted dummy menu just so that I can view the template in a browser without the server side generation mechanism. If I have 100 templates that means that prossibly the exact same dummy menu exists 100x (in each and every template). If I change the look of the menu it's not done with creating a new dummy menu, but I need to copy&paste the new dummy menu into 100 templates.
Even if I decide to do something as simple as renaming my CSS file I need to touch all my templates as well.
There is always the danger that my template looks just fine in my browser, but the generated output is broken because... well... I broke it (could be as simple as a misspelled variable name). Thus I will need to test the output with the actual generation anyway.
Did I misunderstand something there? Or is this indeed a trade-off? How do you minimize the impact of code duplication?
Natural Templates are just an option in Thymeleaf. As you can read here http://www.thymeleaf.org/layouts.html there are many options, including a hierarchical layout approach like the one you seem to prefer (I recommend you to have a look at the Layout Dialect).
However, Natural Templates are the preferred and most explained layout option because Thymeleaf was thought from the ground up to allow you to do static prototyping (in contrast to most other template engines). But it doesn't force you to.
So.. how are Natural Templates applied in the real world to avoid code duplication becoming an issue? That depends on the scenario, but one pattern we see repeated a lot is people creating full document, natural templates for 3-4 or maybe even a dozen of their application's templates, only those that are more likely to take a part in the design process --exchanged with designers, with customers...--, and simply not apply that header and footer duplication in the rest of the application's templates, making their creation and maintenance much simpler.
That way you can have the best of both worlds: a means to exchange fully displayable pages between programmers, designers and customers for the pages that this is really relevant; and also a reduced amount of duplicated code.
What's more, thanks to libraries like Thymol (referenced in the article linked above) you can even avoid code duplication completely, allowing your fragments to be dynamically inserted via JavaScript when you open your templates directly in your browser without running the application.
Hope this helps.
Disclaimer, per StackOverflow rules: I'm thymeleaf's author.
What if use just one html page with blocks inside,
like following
<div id="page1" style="display:block">...</div>
<div id="page2" style="display:none">...</div>
<div id="page3" style="display:none">...</div>
Active block has style="display:block" others "display:none",
when block becomes active "display:block" previous goes "display:none".
AJAX server communication, for instance
$.post("json", { "name": $("#name").val(), "sex": $("#sex").val() },
function(data) { console.log("server responded", data); });
What are disadvantages of this approach?
this is fast and dynamic but this approach lacks of no bookmarking facility, user can't save a particular link because the data is dynamic, also it is not search engine friendly, another disadvantage is history button back and forward will not work.
There are no disadvantages to using pure AJAX. In fact, in a lot of ways, its advantageous.
If you don't plan for it correctly you can have some issues. For example, you're used to having CSS effect 1 page at a time, but with pure AJAX, the CSS will affect every single page.
Also, all things become slightly harder. Linking to another page becomes harder, as you have to use JavaScript.
Lastly, your APP will now REQUIRE JavaScript, so I'd have a decent fallback.
This approach is used in some mobile Web frameworks, such as jQuery Mobile, and is intended to make a Web application feel more native. This is more Web 2.0 than traditional websites or web applications where each page transition involves a trip to the server.
I'm sure you know the advantages already, so let's move on to the disadvantages.
Slightly Greater Initial Latency:
The main disadvantage of this approach is that it will take slightly longer to load the page content due to the fact that you're getting all of the HTML from the server in one single trip. Thus, the initial load time may involve more latency than in a traditional Web 1.0 application. However, with just a few pages, in my experience, the latency is not significant enough for it to be a problem.
Loss of Back Button - More Complexity in Maintaining History:
Another potential disadvantage is that, as a developer, you'll need to approach the development of your site differently. Because you're transitioning pages by hiding one DIV block and unhiding another, you'll lose native back button functionality. This can be mitigated by using the hash in the URL to record the history of page transitions. You'd then need to register an event to watch the hash and reload old content as the user navigates backwards. You'd also need to change the state of JavaScript objects and variables to refect the old state, which may add complexity to your app. There are of course API's and libraries to make this easier to implement and help ensure that you write good, maintainable code.
More Stateful Scope Involves Rethinking Approach and Possible Learning Curve:
Lastly, you'll need to remember that the scope of each page doesn't reset after each transition. While this could actually be an advantage in that your app is more stateful, you'll need to untrain yourself in the way of thinking that each page loaded will cause all of the JavaScript variables and data you've set to be cleared out.
Summary:
My suggestion, if you're going to go this route, is to use a library. Don't reinvent the wheel unless you have a good reason to. Libraries, like jQuery mobile, help ensure that there is good fallback for older browsers, and some even make sure that your site will still load using Web 1.0 techniques for cases where JavaScript is disabled.
I'm sure this is a very old question, but I could not find a straight answer
I'm looking for a works-mostly algorithm to take regular HTML content, and make it email client friendly.
I can rewrite any nice DIV layout to table layout, this is OK, but is there anything that will do it for me?
Here are my concerns
Overflow content - gmail etc ignores any overflow:hidden, the algorithm should address it
Clipped images - same as above, but here the solution will probably be server side clipping
CSS / Script / non standard tags - the algorithm should remove but keep the general look and feel
DIV layout to table layout, I heard it's a must, but I'm sure it's not an easy task to automate
There are many HTML to PDF converters, but I could not find a good HTML to "HTEMAIL" converter
Is there any standard or proposed standard for HTML for email clients? or is it an open jungle out there?
There is no way to make a converter that will be cross email client compatible. The closest you can get is using templates and adding text in certain sections using php or .net
I've been creating emails for 6 months, and the amount of time you spend correcting email client differences is normally around 50% of the time you spend making the email.
Here is some reading that may help you:
http://www.sitepoint.com/code-html-email-newsletters/
http://www.campaignmonitor.com/css/
As you can see from that last link there is no way to create an algorithm that can sort out all these issues.
Hope this helps
Another option that I've been using is to build the email in HTML or directly in Mailchimp. Once I'm happy with it, using Mailchimp, I click on preview and I get the email in a popup. The source code from the popup is email-client friendly (in tables). I then copy that code and use it for my emails.
Not ideal and a bit of trouble, but so far the best solution I can find.
And before people ask, I mostly us Mailchimp directly, but there is one situation that I have to kick it old school.
I have been working on a MVC3 new project where I wanted to introduce the concepts of dynamic themes.
Instead of creating a bunch of .css files and dynamically linking to the
right one, I wanted to use a <style> section in master <head> section
that specifies the values to use for the selectors and their properties.
The values would be pulled from a database and written to header section in style,
look like this:
<head>
<style type="text/css">
.testClass { color:Purple;background-color:LightGreen; }
</style>
</head>
Not an answer on how to achieve this end, per se, as much as a suggestion that you reconsider. I have seen this approach taken firsthand several times over the years, and it invariably ends up first with writing a proprietary tool to edit the database themes and subsequently with an expensive rewrite to extract all the themes out of the database and into proper css files.
One typical reason to go down the path of putting styles in the database tends to be a desire to allow a given style to be "overridden" on a case-by-case basis - for instance, in an application service provider model, where one customer wants to change only one or two of the default styles. However, the "cascading" in "cascading style sheets" allows this exact behavior, without abandoning all the goodness of proper css and the associated tools - as long as you sequence the stylesheets in the correct order in the page head (e.g. "maintheme.css" first, then "customerX.css"), you only need to redefine the styles of interest in the customer's stylesheet and they will automatically override those in the main theme's stylesheet (assuming the css selectors otherwise have the same precedence).
A related, but slightly different reason given for going with database-driven stylesheets is to allow end users or business owners to edit the styles themselves. With a few exceptions, that sort of feature turns out to be less used and more difficult to maintain in practice than it seems when drawing it up. In this case, the number of styles being customized is theoretically quite small - presumably entirely constrained - and you'd be writing a proprietary tool to allow them to be edited, regardless, so again I would suggest simply writing out the customized styles to a css file on a filesystem, rather than a database (or as a blob to a CDN, etc.).
I am developing an issue tracking application in Django, mostly for a learning exercise but also for my own projects - and I am looking into using some AJAX for "enhanced" usability. For example, allowing users to "star" particular issues, which would add them to their watch list. This is implemented in a lot of sites, and is often AJAX - as the URL that the user is viewing doesn't need to change when they click the star.
Now, I am wondering what kind of response to return from my star_unstar view - that detects whether the request is being made via AJAX or not.
At present, if the request is an AJAX request, it returns just the section of HTML that is needed for the star, so I can replace the HTML in the star's parent DIV, so as the star appears "on" or "off", depending on the user's action.
However, I would much rather return some kind of JSON object, as it just seems more "proper", I think. The problem with this method is that the javascript would have to modify the star image's src attribute, the href on it, and the link title also, which seems a lot of work for such a simple feature. I am also looking into in-line commenting in the future, but I want to get a feel for how things "should" be done before I start coding lots of JS.
What is the general consensus when implementing features such as this, not just with Django, but all frameworks that operate in a similar way?
When I work with Ajax my main concern is usually to limit the amount of data I have to send. Ajax applications of this type should be very responsive (invisible if possible).
In the case of toggling a star, I would create the actual on/off states as CSS classes, StarOn and StarOff. The client will download both the off and on star when they first visit the page, which is acceptable considering that the star is a small image. When you want to change the star appearance in the future, you'll only be editing CSS, and won't have to touch the javascript at all.
As for the Ajax, I'd send back and forth one thing -- a JSON variable true/false that says whether or not the request was successful. As soon as the user clicks on the star, I'd change it to the StarOn state and send out the request. 99% of the time Ajax will return true and the user will not even realize that there was some sort of delay in the web request. In the rare case where you get a false back, you'll have to revert the star to StarOff and display an error message to the user.
I don't think your question relates particularly to Django or Python, as you point out at the end.
There's a lot of personal preference in whether you return a blob of HTML to write into the DOM or some serialized data as JSON. There are some practical factors you might want to take into account though.
Advantages of HTML:
- Easy and fast to write straight into the page.
Advantages of JSON:
- Not coupled to the front-end of your application. If you need that functionality anywhere else in the application, it is there ready to go.
My call on it. It's only a relatively trivial amount of HTML to update, and I'd probably go for returning JSON in this case and giving myself the extra flexibility that might be useful down the road.