Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
When you learn HTML and so forth nowadays, the mantra is always "Clean code = better code".
So why do sites like Mobile Me and Google and Facebook all use huge amounts of tables and other not-semantically correct code?
Thanks!
Because people still use IE6, unfortunately, and it's so incredibly bad at CSS as to make it almost worthless for CSS selectors of any sophistication. Until IE6 is gone and dead dead dead in the cold ground, you're still going to see a lot of this.
If you could see what SharePoint generates, you would probably go into seizures.
Clean code is better, yes.
But working code is much much better )
Because sometimes that's the path of least resistance. It's not always about being ideologically pure, it's about being pragmatic and getting the job done in this crazy, multi-browser, multi-platform world.
Because it's easier.
While the purist in me will also strive for semantic tags and external CSS for layout, the pragmatist in me need to get this site up by 6pm (so I can go home to my wife and a nice warm dinner!) and there's just this little problem with [insert browser here*] that could easily be solved with a bit of conditional CSS, or a table or something.
There are other reasons for high-traffic sites like Google and Facebook to use inline CSS and js: bandwidth. Every external file you reference is one extra round-trip to the server to fetch. Of course, that doesn't really explain the style="xxx" tags as opposed to just inline <style> tags, but it still reduces the size of the page. Also, while caching does tend to reduce the number of trips, there are still a significant number of requests that are made with a "clean" cache that you still want to optimise for that case.
Not always IE (but mostly is)
I had an affiliate marketing client the other day who wanted me to make him a web template where he could go in and edit it with Adobe Dreamweaver (some app I don't use because I'm a Linux user). So, being the web-savvy guy I am, I did it in XHTML with cross-platform CSS that I have learned over the years, using DIVs primarily, and only using TABLES for form field alignment simply because of the 80/20 rule. It was lean code in as few lines as possible, loaded super fast, and worked on all browsers from IE6 on up.
But then I handed it off to him, and he was visibly frustrated and asked me to make changes. He didn't like the CSS because he couldn't cut and paste sections to another page and have the styling carry over. Instead, he wanted me to switch everything to inline styles. Next, he couldn't edit the floating DIVs very well, and would undo my cross-platform work I had done, so he wanted it reverted back to tables. The end result was XHTML + CSS for the shell of the page that centers everything into the middle and adds the fancy graphics around the page. Then, I used PHP "include" separation for headers and footers. The final part was the middle of the page, and that was his domain. I had to compose it in TABLEs with inline styles. At that point, he was happy and I had a compromise.
So, keep this in mind that there are some cases where you have to use TABLE formatting and inline styles because that's all the client really knows how to manipulate.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
My girlfriend is making a website for her exam.
She is not good at HTML - at all! (Me neither). But for making it easy for her, I told her to use frames. It's easy and manageable.
But the problem is that the website have to live up to the standard HMTL5. That's a requirement. I don't think frames does that because it's deprecated. Am I right or wrong?
So.. What to do? It has to be as simple as possible. I don't think the other solutions I could find are something she can do herself :( Any ideas?
(Sorry, if my english sucks :) )
You should definitely try not to use deprecated elements. They will behave inconsistently, and probably won't work in the future. There's also a very good reason why frames are deprecated.
You probably need to rethink how you're structuring your data. An HTML page should be as simple and to-the-point as possible. If you have to pull in a significant amount of content from other web-pages using frames, you're doing it wrong. In most cases it's better to simply link to the extra content.
If you're trying to use frames to pull in the <header> or the <nav>, so you don't have to simply copy them across multiple pages, although I applaud you for trying to be DRY, this is the wrong way to do it. Just copying these sections into all your documents is a better solution than using frames.
Ideally though, you'd use a server-side templating system of some sort. The simplest one (depending on your setup) may be Server-Side Includes.
Having said all that, if you really need frames, the <iframe> element is perfectly valid in HTML5 and may help you out.
Don't use frames, very old and not needed at all
Make sure all your style stuff is made in CSS and it's loaded through a CSS file.
Then make each html page with the information needed in it. Use links for navigation to another page.
With the external CSS you can change the look of your site in one file (the CSS file), and it will automatic update for each html page.
You are correct in assuming that frames do not conform to the HTML5 draft (to the extent that it makes sense to speak of conformance to a draft). HTML5 is not a standard, though it may one day become W3C Recommendation. It does not use the term “deprecated” but “obsolete” and “non-conforming”, but in any case, frameset and frame elements do not conform.
The iframe element (“inline frame”) conforms, however. Using it instead of “normal” (old-style) frames is clumsy and limited, but possible to some extent.
I think this answers the specific, on-topic questions asked. The rest is mainly opinion-based and hence off-topic at SO.
P.S. If “living up the the standard HTML5” is a requirement, then the teachers would need a crash course on the basics of HTML5 process. The requirement means that a page that is “standard HTML5” in the morning may become non-conforming before lunch. After all, HTML5 is a draft that may change at any moment without prior notice, and it says itself: “It is inappropriate to cite this document as other than work in progress.”
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I prefer to write my HTML clear, so I may use empty lines here and there - example:
<div>
<!-- Seasons -->
<table class="giantTable">
...
</table>
<!-- Prices -->
<table class="giantTable">
...
</table>
</div>
Today my new workmate told me that this is bad for SEO,
because Google would need more time for parsing the site and may abort with a timeout.
I never heard about this,
shall I really write Spaghetti-Code again?
Google do use page-load and rendering time as one metric (of over 200!) for determining your page-rank, so to an extent your colleague is right (although timeout's are not the issue - he is wrong on that).
However, you can have the best of both worlds :) Write your HTML as you normally do, and then minify it before deployment.
Note that there are a number of tools for analysing your site performance (both online, and as browser plugins - e.g. YSlow), and it's a very sensible thing to do. You can have numerous bottlenecks in your web-site, and can often get some quick wins that significantly improve the responsiveness of your site.
As always with optimisation though - measure first! Don't just randomly implement supposed improvements until you have measured the bottlenecks, and then confirmed the improvement is an improvement.
The sentiment isn't entirely off. Google does now consider the speed of your pages as a factor, and excessive white-space in code can increase payload size. Google themselves recommend minifying your code ( https://developers.google.com/speed/docs/best-practices/payload#MinifyHTML ), and this can be done without too much overhead on the web server.
I find the biggest culprit in dynamic websites comes from using loads of space in the middle of for/while loops, so cutting down on that can make a big difference. Also, try using tabs instead of spaces and you'll cut your white-space big-time.
Even if this were true (which I've never heard before however RBs point above makes a good point), there are many other things that contribute to your page ranking way more than what that would.
Google made an awesome SEO guide which I always check out, its really pretty and easy to read as well, what with all the pictures of Robots. Its definitely worth checking out - Google SEO Guide
It isn't bad at all, they ignore white space. Otherwise everyone would be trying to write code all on one line
http://jamesmartell.com/matt-cutts/is-excessive-whitespace-in-the-html-source-bad/
This document describes how to do SEO for Google (it is quite extensive). A first glance over all the pages doesn't say anything about compressing your HTML.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
IS there a way to test CSS and HTML? For instance: sometimes some of the notices get affected by some CSS changes. I don't want to be testing all the notices by hand every time I do a change.
Thanks
It's very difficult to automate testing of layout. But it's not too difficult to drastically cut down the time and effort involved so that you can do it manually, but very quickly.
You could try Blink Testing.
I've heard of it used for websites like this.
Write a script that walks through your website, visiting as many pages as you can think of.
At each page, take a screen shot.
Combine all the screen shots into a 'movie' with just a second or two for each screenshot.
Now, each day you can 'play' the movie and watch it for any issues.
You could even extend bcarlso's approach but replace the MD5 check with a visual check. Each page gets displayed for 1 second - first the known good, then the new. You could alternate them a few times so any obvious errors will appear as a flicker.
A website with hundreds of pages can be checked like this in a matter of a few minutes. You may not think this will provide enough time to find issues, but it is remarkably efficient in identifying obvious problems with your website.
Any pages that have major layout problems will pop out at you as they don't match the same pattern as all the other pages.
I am assuming that the issue that you're trying to test would be that the CSS changed in some incompatible way with the layout causing, for example, text to be truncated or otherwise visually "broken". If that's the case, then I would say that there isn't a good way to test the aesthetics of a page at this time. One of the primary benefits of TDD and CI is quick feedback so that you know something is broken before it gets to production. Not knowing much context around your environment and how those changes make it into your app it's hard to suggest solutions, but here is an example of a potential non-traditional option:
Put a commit hook into your repository that let's everyone on the team know via an e-mail when someone changes some CSS. Preferably with a diff of the CSS. This would give the team a heads up to keep an eye out for layout problems.
We started an experiment to use WATIR to walk some of the main screens in the app and take a picture using ImageMagik (essentially a screenshot) and store it in a "Last Known Good" folder. Every day re-run the script on a clean install of the app and data and place the images in a "Current" folder. At the end of each run use an MD5 to compare the images and alert on changes. Have the QA team review a list of flagged screenshots and if the change was acceptable (for example, a field was added as part of a feature) then copy "Current" to "Last Known Good". Unfortunately we didn't get our experiment finished so I don't know if it will work well. I'm concerned about the brittleness of screenshots as "assertions".
Hope that helps!
I believe Selenium can test your frontends for you. Specifically for browser compatibility testing, take a look at Selenium RC.
If you'd simply like to make sure you're contents are in the right contents etc. etc. you can create a simple testing suite that's going to be making GET requests to your website. When you receive all the content you can run it through a validation template like xslt. Well formed html will usually be able to be matched against xslt's or xsd's. It is not ideal but if you're only worried about the structure of your website and not the styling you'll be able to achieve it this way.
A change to CSS should not affect the behaviour of a page, only it's appearance, so I'm not sure that Selenium would be much help for this.
I'm going to take a guess that you are trying to avoid problems such as elements being misplaced on the page so that they are not readable. If so, you would probably need some kind of OCR-based tool, but I don't know one off-hand to suggest.
However, it may be to better to invest your effort in preventing this kind of problem in the first place. If your layout is easily broken, maybe you need to refactor your CSS to something simpler.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I'm trying to get in the habit of designing the interfaces to my websites at the very beginning before I do any actual coding. I've read "Getting Real" by 37 signals and they recommend doing the interface first, before any actual code is produced.
What exactly is meant by that? Does that mean use pure HTML and CSS to design the site and add php, js logic to page afterwards, or is it okay to sprinkle in the php, js from the beginning?
What if your using a framework, should I set up empty controllers that simply call the views, or should the early stages be solely html, css?
Also, what do you guys think about design first vs later?
EDIT I'm talking about AFTER I have sketched everything with pen and paper.. I'm taslking solely about the html mockups. And I'm not too sure about using extra tools that I would need to learn to do this
I think that the majority of the benefit of designing the interface first has been achieved after you are done your paper sketches. Basically, you are just ensuring that you have a design in your head and that your coding process is somewhat end-user driven. You are also trying not to waste time on needless documentation.
Getting the HTML in place (or the skeletons of the Views in an MVC app) makes some sense and this is the main thrust of what 37signals says. I would certainly not do anything beyond this that is just going to be thrown away.
I think if you have a proper design, it is immaterial if you next move on to writing the back-end code after the HTML or if you do the CSS and JavaScript. The CSS and the code should not even need to be aware of each other.
Do whatever gets you excited and motivated. Do whatever gets you thinking more deeply about how the app will actually work so you can catch any flaws in your original thinking. I like to code before CSS but that is just me. You might find it important to get the CSS further along before the app takes shape in your head.
Joel Spolsky likes Balsamiq as a mocking tool. I think that 37signals uses Draft (an iPhone app). I use a Sharpie. The key is not getting too detailed though.
Opinions vary, but I believe that JavaScript should come last. I believe most sites should be designed so that they work 100% without JavaScript and then have JavaScript added for polish.
Learn more about Unobtrusive JavaScript
So (for me):
Quick and dirty sketches of views
Get some HTML in place
Maybe some basic CSS for layout (or more if I need to impress somebody early)
Write the core logic
Add support for web services and AJAx calls
Pretty it all up with snazzy CSS
Write some JavaScript to add the sizzle
Let me ask you this. Do you paint a car before or after you have made the working parts? Maybe you have chosen which paint but ultimately it cannot go on until the car is finished. Maybe you don't agree with this analogy but I think coding will bring out issues that cannot be understood before a site is designed. Code first, design second.
Get a pad of paper. Each page represents one page of your site.
Sketch the interface. What controls go on each page? What controls are the same on each page? What forms are there and on which pages? What happens when user clicks on item x? Item y?
This will help you solidify your plan of both the content and behaviour of your site.
If you just start blindly coding you will end up with burnt spaghetti.
The user interface is what the users of the website will see. Before coding you probably start with some very basic sketches of the site that are not code, to identify page navigation, general placement of content and interaction with the site.
But the earlier you can show and discuss a working UI, the easier it is for the users/client to get an idea of the final product. So quickly move to the HTML, CSS, JavaScript and things like images, to identify:
The data presented on the page (HTML)
The representation of the data (CSS)
The interaction with the data (JavaScript)
Doing so helps to gradually develop an actual working UI that you can discuss with the client. This keeps them involved from early in the project. It forces them to think about the site, and make decisions about content, look and interaction.
Getting such feedback early in the project reduces the risk of building a product that needs to be changed later on. And making changes early in the project is easier/cheaper, then later in the project.
While the UI is being developed you can already start looking into data structures, software components and integrations with other systems to drive the site. But that's not what users/clients are interested in, they want to see and use the product.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I haven't used frames since 1998. They seem like a bad idea and in all my development I've never had a situation where frames were the right solution, or even a decent solution.
However, I'm now working with an internal web application written by another group and the entire site is built in a - header, left side menu, right side content - frameset.
For one, when VPN'd to my network I constantly get a "website.com/frames.html" cannot be found." error message. This doesn't happen when I'm on the internal network.
Second, the app has a built in email/messaging system. The number of unread messages is shown in the left side menu frame as "Messages (3)" but the count doesn't update as I read the messages. The developer told me since it was in a frame I needed to right click on the menu and 'Refresh'. Seriously????
So, my programming related question is, what reasons do you have for not using frames in a website?
Although they solved a problem at the time they were created (updating part of a "page" while keeping in place a non-updating part), framesets were criticised in terms of usability pretty much from the start, as they break generic functions of the browser, such as:
bookmarking, and copy-and-pasting URLs to share
printing the page as displayed on the screen
reloading the page: since the URL has generally not changed, you will often be taken back to the site's homepage or default frameset; manually reloading some frames is possible, but not obvious to the user
back and forward buttons are ambiguous: undo/redo the last frame change, or take you to the last time the URL bar changed?
The heaviest burden of avoiding framesets - including the same content on every page - is trivial to solve if you are using any server-side language to generate your HTML, even if all it provides is a "server side include". Unlike framesets, a server-side include could occur anywhere on the page; building a site with a server-side scripting language or templating system has other obvious advantages too.
There is still an advantage to being able to update small areas of the page without reloading the entire content, which can be achieved via AJAX. This sometimes leads people to create interfaces with all the problems of framesets outlined above, but that is hardly an argument in favour of framesets. Again, a site built with well-designed AJAX functionality can achieve things which framesets don't even begin to address.
One good reason to avoid frames today is they have been deprecated in HTML 5: Chapter 11 Obsolete features
11.2 Non-conforming features
Elements in the following list are entirely obsolete, and must not be
used by authors:
[...]
frame
frameset
noframes
Either use iframe and CSS instead, or use server-side includes to
generate complete pages with the various invariant parts merged in.
The #1 reason? Users hate them.
Even if they offered advantages in other areas (separation of code, application design, speed etc) they are part of the user interface. If users don't approve, don't use them.
Frames were vaguely useful when you had a static web site, to avoid repeating navigation menu in all pages, for example. It also reduced the overall size of a page.
Both these arguments are obsolete now: sites don't hesitate to serve fat pages, and most of them are dynamically built so including such navigational parts (or status, etc.) has no problem.
The "why" part is well answered above, partly by your own question (you hit a limitation, although it can be overridden with a bit of JS).
My number 1 reason not to use frames is because they break the bookmark (aka favorite) feature of browsers.
With the technology that exists today, frames have become obsolete. But if your legacy project still uses them, you can make the messages update with some ajax.
Just because of the cell phone iPad craze doesn't mean that highly functional full featured sites are suddenly "obsolete", and those who decided to make framesets obsolete seem to be the same complainers who never figured out their full potential in the first place, or maybe they're the lobbyists of the mega-corporate cell-phone and tablet makers who couldn't be bothered to make a decent frames capable browser for their itty-bitty screens.
Admittedly, iFrames can handle simple jobs like scrolling and/or displaying independent segments within a single page pretty well, and I use them for that inside my own frames based website, but to get them to work as well as the foundation for a site itself is a nightmare. Trust me, I know because my website is one of the most sophisticated frameset based sites on the Internet and I've been looking at the pros and cons of transposing it all to iFrames. Nightmare is an understatement.
I can already hear the whiners saying, "Well why did you build it that way in the first place then?" ... and the answer is A: Because I'm not lazy. and B: Because a frames based site is the most functional, visually appealing, and user friendly format for an information based site with hundreds of pages of content that doesn't have to rely on a server. By that I mean all but the external advertising can be viewed straight off a flash drive. No MySQL or PHP needed.
Here's some of the issues I've encountered:
The objection to orphaned pages can be easily handled with JavaScript.
The objection regarding bookmarking is irrelevant unless you use no frames all.
Content specific bookmarking can be handled with an "Add Bookmark" JavaScript function
The objection regarding SEO is easily handled by an XML sitemap and JavaScript.
Laying out dynamically sized frames is far easier and more dependable with standard framesets.
Targeting and replacing nested framesets from an external frame is easier with standard framesets.
In-house scripts like JavaScript searches and non-server dependent shopping carts that are too complex for cookies don't seem possible with iFrames, or if they are, it's way more hassle to get them working than using standard frames.
All that being said, I like the single page appeal of iFrames, and when they can actually do all the same stuff for my site as easily as standard frames does now, then I'll migrate. In the meantime, this nonsense about them being "obsolete" is as irksome as the other so-called "upgrades" they've foisted on us over the years without thinking it all the way through.
So what does all this boil down to for the question of whether or not to use framesets? The answer is that it all depends on what you want your site to do and on what platform it will mostly be viewed on. At some point it becomes impractical to make a multi-page site work well without some frames or iFrame integration. However if you're just creating a basic profile page that displays well on a cell phone or tablet, don't bother with framesets.
They almost always make people angry. What more do you need?
Frames are really useful in some occasions. If you are creating a local webpage that serves only for reading, no interactivity involved and the website will not be public on the internet, all the reasons on not to use frames are removed. For example a user manual for an application that is developed solely in html, frames are really useful in keeping a table of contents on the left in a simple and easy to code way. Also if you have proper navigation within the website then the back button ambiguity is removed completely