I understand this, but it seems that some frameworks don’t even follow the correct html hierarchy putting tags in the wrong place.
I’m looking at reducing the number of frameworks I use as I recognise knowing one framework really well makes development easier. This really helps in choosing a framework. It’s also a great indicator if a developer takes the extra effort to create great code even if no-one but the web browser sees it.
I really think the learning curve for F6 isn’t as bad as some folks seem to think. It could sure use a lot more written documentation. A lot of the learning is still video, great for getting a feel for how the framework works, but not good for an ongoing reference while you 're putting a site together.
To get ride of all that unnecessary code that’s generated by most stacks, Joe made all the F6 stacks inline stacks. That removed the controls to set the background, border, layout (margins and padding), and responsive (hide this stack on mobile, tablet and desktop) on every stack. Instead, you set these kinds of styling settings in what he called a swatch stack. Then you just apply the “swatch” name (usually a class name) to the stack that you want to make those styling changes on.
Once you get your head around this approach, it’s really easy to comprehend. You are separating style from content. This was the primary philosophy of the development of HTML5 and CSS3. By separating the content from the style, it makes it much easier to change the look and feel of an entire site or just portions. If you want to have a look at this in action, check out the CSS Zen Garden. Just select a style and see how the site changes with no change to the HTML Content.
I find it also benefits in creating content. If you focus on the content, and forget about how it’s going to look while you’re writing, I think you’ll end up with better content.
Once you get used to using swatches in F6, you’ll find ongoing changes much easier to apply. How many times have you setup color schemes when either you or your client reconsidered. The traditional stack way might require you to go into multiple stacks on multiple pages and make these styling changes. With the Swatch approach, you would only need to change the swatch and republish.
One of the issues here is with the kinds of sites you want to build, and the way you like to work. A framework with lots of pre-defined classes is very efficient if you‘re using those classes a lot. But if you‘re not using them, your site is carrying a lot of bloat (and you run more risk of conflicts).
Where it gets really messy is if you‘re using a ‘big‘ framework and you‘re using stacks which bring other frameworks with them. (For instance, I‘m a devotee of Rapidcart, but I really don‘t need it bringing UI Kit with it, and other stacks do the same with Bootstrap).
So it‘s ‘horses for courses‘ — Stuart‘s minimalist approach with Source works well for people like me who are promiscuous with stacks, but for someone who is happy with the (often excellent) stacks that are part of a framework, it wouldn‘t make any sense. And whichever way we go, there will be trade-offs (the lightest and spareist way of building RW/Stacks sites would probably be with Source/BWD — but it‘s unlikely that will do everything we need a site to do).
We first need to find our style, and then work out how best to optimise from that. (And, actually Squashing those images will achieve much more than worrying about the amount of unnecessary css you‘re carrying.)
I think the key point of the original poster was to ask about HTML Semantics. My samples above are about HTML not CSS blot, image optimization, JavaScript, jQuery or really anything to do with page weight or speed.
You won’t get any argument from me that most newcomers at site building and even some professionals need to remember to crop those images and run them through an optimization application. And most beginners probably need to consider more carefully what images and even videos they are using. Do they help convey the subject, or are they just there for decoration or to fill space? We can go on and on about website Blot and performance, but let’s get back to the subject.
One of the most important features of HTML5 is its semantics, the syntax that makes the HTML more comprehensible, allowing for search engines, screen readers, automatic bots, and browsers to better interpret content. For example, you can just take plain text and make it as large as you like, but it doesn’t have the same meaning as a <h1> tag. The <h1> tag is HTML semantics, visually semantics doesn’t make any difference, but to search engines and screen readers, it makes an enormous difference.
Google bots, Bing bots, and other “non-human” visitors may make up more than half of your website traffic. Most every website developer wants to do well with search engines, many folks spend a lot of time worrying about SEO. We have all heard from the powers at Google that content is what’s important. So why wouldn’t you take the time to use semantics correctly? If it makes things easier and from both Google and Bing, it does, why not do it.
Now will Google, Bing and the other search engines index your pages without semantics, of course they will. They will make every attempt to figure out what the page is about, even if you don’t have a single HTML tag on the page. But why rely on the bots to guess what’s important. Finding blocks of meaningful content correctly tagged, is going to be significantly easier than searching through endless divs. It will give you more control of what gets indexed.
In fairness the original question adds “and also outputting as small a footprint as possible”.
In terms of what seems to be the general interpretation of ‘semantically correct code’ (that a heading is a heading, a table has rows and columns and a list is… well, a list) pretty much everything these days is ‘semantically correct’ (maybe a dropdown which is an unordered list is pushing it a bit, but not so much). Back in the days when we had to used tables for layout, and there were lots of kludges to get HTML to do what it wasn‘t intended to do, it was different. Now we have tools for pretty much everything.
Picking through the source generated by stacks from lots of different stacks providers, I can‘t say that I really see any HTML that isn‘t ‘semantically correct’ — there is no reason now for it not to be. Sometimes things may get buried in a few layers of divs, but that‘s not really a semantic issue. The source is readable. And it‘s pretty clear what‘s doing what. Some of it is tighter and tidier than others, but there are plenty of good devs in this community as well as the exceptional ones.
So I had a chance to look at some of the code on the platforms recommended. There is a difference between them. Stacks is a huge plus in regards to creativity when using RapidWeaver. But no matter which version you use, you get a lot of bloat as compared to hand coding. Just looking at some of these — at least 4x’s or more wasted html AND css. For that reason I am still out. A custom made theme is a far better compromise.
…is your opinion 
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.