[高流量网站的CSS设计].(Pro.CSS.for.High.Traffic.Websites).A.Kennedy&I.d.Leon.文字版.pdf

Contents at a glance Foreworduuuuxvit About the authors About the technical reviewer XX Acknowledgments AEBEBAAIBBBEBIRIBIHIBHRHIEIRBHRBRIBIRBRBHBEAIaD Prefacemmmmmm xXi Background Information BBHIIIRBRBRIRH HBHBHIEIHBBHRBERIHIBBERBIIRI Chapter 1: The Value of Process mmIB ■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■ Chapter 2: CSS Style Guide ■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■ Chapter 3: Fundamentals Chapter 4: Frameworks and Integration ■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■冒■■■■■■■■■■■■■■■■■■■■ Chapter 5: Brand Implementation. ■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■ 137 Chapter 6: CSS and accessibility ■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■ 165 Chapter 8: Performance BEI BmHHmHm 223 Chapter 9: Dynamic CSS mIa ■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■ Chapter 10: Testing and Debugging ■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■ Chapter 11: Creating Your CSs mmmmmmmammmaaaammmmmmaamaaamaa 331 Appendix 1: cSS Standards Guide ■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■ 361 Appendix 2: Accessibility Guidelines ■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■L■■■■■■■■■■■■■■■ 369 Appendix 3: Browser Support Guidelines ■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■D■■■■■■■■ 373 Appendix 4: Development Process B ammmamaummmm 377 Index ■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■ 383 Background Information This book assumes certain pieces of knowledge on the readers part. This section aims to ensure that you are aware of these pieces of information, and explain what you can get out of this book. Seasoned developers or anyone who has been working in the web industry for a reasonable amount of time should be able to safely skip to the first chapter Who s this book for? Although we will be providing examples of CSs code to demonstrate techniques and subjects we are covering, these are not to demonstrate the latest selectors or properties, but instead to demonstrate how to format, comment, and model your code to keep it sane and follow best practices in your processes To that end, this book is about the entire team as much as it is about the developer and should be of value to all of its members This book is for the following Anyone working on a high-traffic website. This is any website expecting upward of 10,000 unique visitors per day, or with occasional spikes of traffic higher than this amount Anyone working on a very large website one with perhaps upward of 2,000 individual pages or with more than 30 minisites Anyone working on websites in companies with large amounts of staff modifying the same codebase, with upward of 30 developers working on the CSS Anyone working for a company with the capacity to become a very large company and wanting to build a good basis for its web development processes. Developers without previous experience of working in large teams However, the practices involved are best practices for websites of any size What will i learn? Throughout the course of this book, you will learn the following The value of process How to share knowledge among staff and teams XXII BACKGROUND INFORMATION How to quickly get new CSS developers up and running How to incorporate CSS into builds and deployments how to write reusable and modular css How to maximize performance of your website(s) How to keep branding consistent Best practices for cross-browser and accessible css Dynamic CSS techniques The final chapter provides a simple css framework we developed specifically for this book that demonstrates many of the things that we touch upon as well as the process we have followed to build it The four appendices provide concrete examples of guides and processes that you should find useful Why Is This book Different From others? Belore embarking on the writing of this book, we did much investigation into which alternative resources were available. A plethora of books on learning the basics of CSS, advanced CSS techniques, CSS3 selectors/properties, and different Css design patterns are all easily obtainable This book does not compete with or replace these titles. This book instead explores the challenges of working in large teams or among large numbers of individual teams, on sites with many pages or subsites that receive considerable traffic. This book is not about using the latest and flashiest techniqu for image replacement or cross-browser rounded corners; rather, it is focused on making it easy n r ques newcomers to teams to easily comprehend and add to existing code, and for css within your infrastructure to be considered from the outset and built in a sane and performant manner Even though this book is aimed at both beginners and experts alike, we assume that you are comfortable using HTMl and css, or are at least familiar with their syntax. We will be discussing the usage of modular, reusable code that is both robust and practical throughout the chapters in this book. Separation of concerns Separation of concerns is an important concept to understand when writing css many different Architectures for applications and systems exist. The justifications and benefits of them are far beyond the scope of this book; however, it is worth giving a very simple explanation of multitier architecture since the logic behind it is easily applicable to CSS and the browser application model A multitier architecture approach is a design that separates logic, data, and presentation. This usually describes a client-server system, where there is a client application and a server application. The majority of the processing takes place on the server, and the client is concerned with displaying the information and giving the user an interface to manipulate it. The multitier approach applies as such Client application: presentation · applicatior: logic Model view Controller(MvC)is an example of this BACKGROUND INFORMATION Server data Separating the tiers in this way gives clear ownership of any particular piece of code, function, or task. It also keeps everything reusable and easily maintainable This is how more traditional client-server applications would typically behave. This approach obviously applies to a web browser, web server, and database but the code that runs in the web browser can also be broken down this way. We typically write our front-end code in three "languages": HTML, CSS, and JavaScript. It is possible for our code to be all jumbled up together, much like the following example ka id="clickableAnchor"href="#"style="color: blue; "onclick="alert('clicked! ) >Click me Technically there is nothing wrong with this; the text will be blue, and the JavaScript will run when it is clicked. However, there are several reasons why this kind of code is bad practice: There is no clear separation of the different types of code. When CSs developers want to change the color of the text, they cannot do so with modifying that page. When JavaScript developers want to change the text in the alert box, they cannot do so without modifying that page There is no way this code can be reused. If all our code was written like this and it was decided that all anchor text should be red we would have to modify the code in every single place where there was an anchor The more code there is on the page, the larger the file to download. In a way, this is restating the previous point because reusable and extermal code need be downloaded only once. This, however, also has implications for search engine optimization (seo) Fewer types of code in a document make it easier to read, parse, and edit a more appropriate solution would be the following In the head #clickableAnchor color: blue; 1 script〉 $(#clickableAnchor)click(function (i alert(clicked! ' We have used jQuery for this example to keep things simple. We are not advocating jQuery over any other javascript library or framework XXIV BACKGROUND INFORMATION In the body click me/a> solution. This method breaks our three languages apart; it is much tidier, but there's an even better In the head: Click me This solution finally separates our three tiers; it creates separation of concerns. Now these files can be easily shared across many pages and cached for better performance. Our tiers relate in the front end realm like so HTML: data CSS: presentation Javascript: behavior Let's touch on these in a little more detail Data For the purposes of websites, we usually refer to this as content rather than data. you will often hear the phrase "Content is king, "and this is good advice. Your markup should be semantic and well structured on its own, it should read as a valid and sensibly ordered document. This ensures that machines as well as humans have a good chance of understanding both the intent of the content within the document and the words. If a piece of content is a heading, it should be marked up as such(instead of being marked up as, for example, a paragraph set in bold); if it is clearly a list ofitems, it should also be marked up as such(as opposed to a succession of divs or some other less relevant element), and so on. When machines understand our intent, they have the ability to do the following Understand what a about and which parts are more/less important this is especially important for search engines and assistive devices Display the page in different ways without affecting legibility (for example, by tile sheets). This also that des gracefully in older browsers and display your content in a way that does not apede comprehe XXV BACKGROUND INFORMATION Allow access to the data in a nonlinear fashion, which is, again, particularly useful to assistive devices Presentation This layer concerns itself only with how the page looks Anything superficial or purely decorative goes here. If you are choosing the font, laying out a page, or changing colors, this is the appropriate layer. If your branding calls for text to be in lowercase or for very small headings, we can do that in CSS without ruining the semantics of the "true"content in our page. Behavior This is sometimes called the Logic, Business, or Business Logic layer Where we are interacting with the page in nonstandard waysfor example, dragging and dropping, or making Asynchronous JavaScript Across XML (AJAX) requests(a method of fetching information from the server without requesting an entirely new page), the JavaScript is the part responsible for this Front- End development Is Full of Exceptions Although the resulting benelits of the tiered approach are clear, it is never as clear-cut as we have just made it seem. Expressions can reside in Css iles, making calculations (although we do not advocate it JavaScript can be responsible for presentation(such as the appearancelanimation of menus Sometimes Javascript is responsible for adding new content to the page. There are many other examples. However, intending and attempting to separate the layers in this manner gives us a good starting point, and approaching web development in this way can often result in new and clever ways to avoid duplication of content and maintain high performance With these basic pieces of information under our belt, we're ready to get started. The first chapter will introduce you to the importance of process. Although not strictly a Css subject, it is an important base to build vour projects upon XXV CHAPTER 1 The value of process In this chapter, we aim to focus on how processes in your team and company can help rather than hinder your productivity. Many of these topics are not specific to css( Cascading Style sheets), but to write CSS that is scalable and shared among many teams or websites it is vital to have solid processes and consistency. We willtalk about development methodologies, how to ensure consistent code styles, source control, tools, and naming conventions. Because we aim to give you useful practical examples, we will present an example process at the end of this book In this chapter, we will look at The team and its parts · Scaling a business Dealing with loss of staff a Consistency of code OOls Version control · Backup · Prototyping Development methodologies The team Arguably, the most important element in CSS development is the team that supports the developer every team is different, not just the personalities of the members or the sizes of the teams but also the disciplines and skills within it. Some teams include a few server-side developers and a single front-end developer, some include the entire skillset required to build a web solution: designers, Iront-end developers, server-side developers, database specialists, testers, and so on a team this size has the benefit of rapid communication between its component parts but has th disadvantage of size; larger teams are slower to respond to requirements for various reasons. The primary reason for this is something researchers call"diffusion of responsibility. This means that in larger teams, members assume that someone else is doing any given task at any given point rather than taking it upon themselves to do it. Without clear guidelines in place, it can be difficult to be sure of who is or should be responsible for unexpected problems or tasks, so even though these issues are noticed, they are forgotten. In smaller teams, besides communications being more immediate and effective, more attention is on each individual, and members will assume responsibility and be more proactive CHAPTER 1 THE VALUE OF PROCESS This issue, however, can be overcome with good project management. If you have all your tasks mapped out with clear areas of responsibility, there is no room for confusion. NOTE: There are many terms that describe people that write CSS: front-end developers, client-side developers, web developers, and web designers are just a few The processes within your company change dramatically depending on the type of team you have. For teams that do not include designers, if the requirements fed to your team already include complete designs and specifications, there is little room or time to feed back any issues to the designers or information architects and the development is more siloed away from the requirement creation process If the teams do not include testers, and the user testing process is outside of your team,errors or problems they find are fed back to you after you have finished developing, which is the least efficient time to fix them It also makes a big difference who writes your CSS. If it is written by web designers(hopefully the same people who made the designs for what you are developing then as long as they are good at what they do they will have taken into account things like accessibility, usability, and templating. If the designers are separate from your team, you may find the designs they provide do not intrinsically consider these things. The worst case is where the CsS is written by those who don, t specialize in front end code at all because they are not expert in what they are doing, and may do more harm than good CSS is deceptively simple, and it is easy to write inefficient bloated code that quickly becomes legacy code. However, companies' processes are often based in legacy and not that easy to change. The project manager is responsible for getting the most out of the team and dealing with these issues. One of the most important pieces of a process is delining areas of responsibility. These areas need to be mapped out clearly before a team is even put together, so you know who to include in the team. A simple example is as follows the business (as well as the business to the team), ensuring that everything ls o Project Manager: The project manager is responsible for representing his team recorded correctly, facilitating meetings, and making sure that the members of his team know what they should be doing and have everything they need to do it (including helping to remove any obstacles that prevent them from doing it). As far as the team goes, the buck stops here; if a project fails, it is likely to be the project manager that is held accountable Team Lead/Technical Lead: Team leads are responsible for the technical delivery of the product. They need to ensure they understand the general direction the project is going in as well as the methods being used to address technical challenges, and to communicate with members of their team to ind any potential risks or pitfalls, and suggest ways to resolve them Developer: The term developer is a broad term. For the sake of this example, the developer is the person undertaking the actual tasks within the project(writing the CSS). He is responsible for giving estimates and details necessary to record the tasks, feeding back technical issues to the team lead and logistical issues to the project manager, and completing the tasks With these roles clearly defined, it becomes obvious who should be doing what. With regular meetings any problems should be located and dealt with quickly