I have a messageboard and one of my users has written a greasemonkey script to stylize various elements within the page. He did a great job with it but in order to make his job easier, the first step in his script is to parse the current page and add several css classes to almost all html elements on the page. most of them aren't used to style the page at all, but instead to make it easier for him to query the couple elements per page that he will actually modify. for example class="thread_started_by_user_123 thread_with_456_posts thread_with_789_views thread_last_posted_in_by_user_12345" etc etc
is this a standard practice? are there any downsides to adding lots of unnecessary css classes, either in javascript, or on the server if i were to add them to served pages too.
This looks to be using classes to embed arbitrary metadata into elements, which is certainly not what the class attribute was designed for. Given that its effects begin and end with a greasemonkey script and are thus localized to the client, it seems a harmless enough hack, but not one I'd advise duplicating on the server side.
HTML unfortunately doesn't provide much in the way of alternatives when it comes to metadata other than sticking in invalid attributes, so there is a mechanism that does add semantic meaning to the "class" attribute within existing tags -- namely microformats. There's a lot of breathless buzzwordy hype around microformats, but overall they do revolve around a best practice for areas where going all-xml is out of the question.
In terms of semantics, yes there are downsides. If you have classes that aren't descriptive of what the element actually is and are there for styling purposes only, this can hurt you down the road should you decide to redesign and/or restructure.
for instance, BAD:
<div class="header red left-side">
GOOD:
<div class="header main current-event">
If there is no associated style with a class that's assigned to element, then I believe the browser will just ignore it. So it will not increase your page processing time a lot if that's what you are worried about.
However, if there are lots and lots of classes for each element, then you have to realize that you are using valuable bandwidth and increasing the time it takes to load the entire page that way. You can avoid that problem by externalizing the CSS so that the browser can cache it.
Are you using jquery to query the elements that you really want to modify? It might turn out that its more easy to pick those elements with jquery selectors which seem difficult or impossible with standard JavaScript and thus you can possibly avoid all these extra unnecessary classes.
Bottom line, there is no problem in using lots of classes if they are needed, and that's perfectly fine for production, but if you don't need them, like in your case, there has to be a better solution that you can possibly come up with.
Just for a data point, I took a look at GMail's HTML yesterday (their buttons are very nice) and it's full of that kind of thing.
Here's an example:
class="goog-imageless-button goog-inline-block goog-imageless-button-collapse-left goog-imageless-button-collapse-right"
Classes are not just for CSS, they're for the categorization of sections of markup. Applying styling based on that categorization is just one use. So if the classes are useful for other categorization purposes then that is fine, and perfectly good practice.
Related
I'm tasked with evaluating some legacy web pages (classic asp) for accessibility. You can assume the HTML is not perfectly formed and that it's loaded with inline javascript and that we make use of javascript libraries that vomit HTML to create dynamic features. It's a circus in there.
While I recognize that the obvious answer is to re-write the page(s), that's not an option in our given time tables. So I'm trying to find the best way to make the pages work with a screen reader. Here's what I think I know.
We can use JAWS scripting to instruct the browser how to read the page.
We can use ARIA attributes to give the pages better organization and structure.
Specifically, I'm trying to figure out:
Question 1) If a JAWS script is present, will it be used exclusively by the browser/screen reader and ignore any improvements I make in the underling HTML structure?
Question 2) Could some well-place ARIA attributes give the page enough structure so that the default screen reader properties will work in an acceptable manner (without a JAWS script).
Question 3) I suspect the tough answer is that I would need to do both, which I'm trying to avoid because we barely have the capacity to do just one. But we don't want to lose a customer, of course. :-(
Many thanks for any input.
Instead of explaining only to JAWS how to access your pages, use JavaScript to explain it to any Assistive Technology (AT) for the web. I expect the same effort, while it will profit way more users.
In a JAWS script you would need to describe ways to access DOM nodes that are not accessible. That would include
speaking out information that you have to find elsewhere on the page
adding keyboard navigation where it's missing
Both can be done in JavaScript, probably even easier (you'll need to address DOM elements).
What you will need to avoid is restructuring the DOM and changes to classes, since those are most likely used by the scripts that generate them.
But I'd expect that adding attributes and keyboard handlers will do no harm to the existing scripts. Beware of already existing handlers for focus or keyboard events, though.
I would recommend making a list of attributes and handlers you suspect to conflict with the existing scripts, and searching the scripts for these, like onkeypress or onfocus event handlers.
The absolute best way to make your application/site accessible is to use semantic HTML. It doesn't matter if that HTML is generated by asp or jsp or whatever.
If you have a table, use a <table>.
If you have a heading, use an <h2>.
If you have a list, use a <ul>.
Use <section>, <article>, <nav>, <aside>, <header>, <footer>, etc
That's how you create structure on your page that a screen reader user will appreciate.
If you can't use native HTML, then fall back to ARIA, but treat it like salt. A little bit greatly enhances the flavor but too much spoils the meal.
If you can't use a native <h2>, then make sure you use the appropriate role and attributes.
<div role="heading" aria-level="2">this is my custom h2</div>
If you can't use a native <header>, then make sure you use the appropriate role and attributes.
<div role="banner">my header stuff goes in here</div>
I would recommend totally forgetting about JAWS scripts. It doesn't matter if that's what the customer thinks they should focus us. It's not about that customer. It's about that customer's customers. The end users. They should be able to use whatever screen reader they are used to using and most comfortable with. That's the whole purpose of accessibility - making the site usable and accessible by as many people as possible using whatever assistive technology they are used to using.
Following the Web Content Accessibility Guidelines (WCAG) will lead you to that result.
Regarding inline v. internal v. external CSS, I understand the cacheing issues, and the tradeoff between multiple downloads and single downloads of larger files. What I would like to know is how rendering speed varies, based on the three places you can put CSS.
In other words, what takes the least time to actually draw the page? I assume that external is the slowest, because even if it's cached, the browser still has to retrieve the rules, parse them, and apply them to the current elements. I also assume that internal (in the page but inside style tags) would be second slowest, because there's still the process of parsing the rules and determining which rules to apply to which elements. And I assume that inline (applied directly via style attribute) is the fastest, because the browser can skip the process of matching rules to elements.
Anybody ever looked at this in depth? I know that I've had some rendering problems on large pages with complex CSS that could only be solved by going inline. (Please, no lectures on the evils of large pages with complex CSS.)
either way, once the actual rule text is loaded, it's run through the same css parser - there aren't different parsers for external v.s. internal css. it's all just css. External might be a bit slower to get applied because it'll require an extra HTTP request to fetch that file, but once it's transferred to the host browser, it'll parse just as fast as if you'd physically embedded the same rules in an inline <style> block.
I don't think you should care which mode is fastest. HTML, CSS and JS are not meant to be fast in any case.
I think you should worry about readability and maintainability, think about managing a webpage with styles directly applied inside HTML tags. You wouldn't be able to manage anything complex in that way.
What you are asking mainly depends on browser implementation (with respect to the css file that could be downloaded separately according to which solution we are talking about). In any case I don't think the difference is so much considerable just because they all need to be parsed by the same parser.
If a page is really too complex to be styled with a stylesheet and requires inline style then the problem should be solved not by having inline css but refactoring things at a different level.
In addition I would say that many performance issues could be caused by writing CSS just without any kind of structure, just adding things day by day without even considering having strict/clever selectors. Developing things while thinking about them (that is something that is usually left behind in web development, especially with front ends) usually is the best way.
I am developing a "bar" like what you see on the top of many default Blogger blogs that acts as a unifying element on otherwise different-looking sites. I want to package the code up into a neat package so that I can give other developers a few simple lines of code that they can paste into the beginning of their <body>.
I know there are many ways to do this, like using PHP includes, AJAX calls, JavaScript and XmlHttpRequest, Google closure templates, etc. BUT I want to make sure the bar is CSS independent, meaning other CSS that is used on the site does not affect my bar.
I am wondering what is the best method to accomplish this? Is inline CSS the only way around this?
Just like JavaScript plugin development, there's no guarantee that CSS classes and IDs wont be overridden later.
If the code needs to be inline, I'd suggest namespacing all of your classes and IDs: pluginname-wrapper, pluginname-container, pluginname-block, etc.
Otherwise, you could use an iframe element to store a miniature page.
I'd suggest sticking to namespacing. If someone includes your plugin and it's off by a bit, they'll be able to manually override the styles to make it look the way they want.
Someone who writes div {float:left;} or anything similarly silly will have problems either way, so don't worry about making it the same for everyone, just make it work with the default styles.
I'm implementing "news" section in asp.net website. There is a list of short versions of articles on one page and when you click one of the links it redirects you to a page with a full article. The problem is that the article's text on the second page will come from database but the articles may vary - some may have links, some may have an image or a set of images, may be differently formatted etc. The obvious solution that my friend have come up with is to keep the article in the database as html including all links, images, formatting, etc. Then it would be simply displayed on the second page. I feel this is not a good solution as if, for example, we decide to change the css class of some div inside this html (let's say it is used in all articles), we will have to find it and change in every single record of the articles table in our database. But on the other hand we have no idea how to do it differently. My question is: how do you usually handle something like this?
I personally don't like the idea of storing full html in the database. Here's an attempt at solving the problem.
Don't go for a potentially infinite number of layouts. Yes all articles may be different but if you stick to a few good layouts then you're going to save yourself a lot of hassle. These layouts can be stored as templates e.g ArticleWithImagesAtTheBottom, ArticleWithImagesOnLeft etc
This way, your headache is less as you can easily change the templates. I guess you could also argue then that the site has some consistency in layout.
Then for storage you have at least 2 options:
Use the model-per-view approach and have eg ArticleWithImagesAtTheBottomModel which would have properties like 1stparagraph, 2ndparagraph, MainImage, ExtraImages
Parse the article according to the template you want to use. e.g look for a paragraph break if you need to.
Always keep the images separate and reference them in another column/table in the db. That gives you most freedom.
By the way, option #2 would be slower as you'd have to parse on the fly each time. I like the model-per-view approach.
Essentially I guess I'm trying to say beware of making things to complicated. An infinite number of layout means an infinite number of potential problems. You can always add more templates as you go if you really want to expand, but you're probably best off starting with say 3 or 4 layouts.
EDITED FROM THIS POINT:
Actually, thinking about it this may not be the best solution. It could work depending on your needs, but I was wondering how the big sites do it. If you really need that much flexibility, you could (as I think was sort of suggested) use a custom markup. Maybe even a simplified or full wiki markup. I'd still tend toward using templates in general, but if you need to insert at least links and images then you can parse for those.
Surely the point of storing HTML with logically placed < div >s is that you DON'T have to go through every bit of HTML you store to make changes to styles?
I presume you're not using inline styles in your stored HTML, and are referencing an external CSS file, right?
The objection you raise to your colleague's proposal does not say anything about the use of a DB. A DB as opposed to what: files? Then it's all the same. You want to screw around with the HTML, you have to do it on "every single record." Which is not any harder than "on every single file." Global changes are a bitch unless you plan for it by, say, referencing an external CSS. But if you're going to have millions of news articles, you had better plan on versioning the CSS as well.
Anyway, the CMSes do what you're thinking of doing. Using a DB is a fine way to go. How to use it would depend on knowing the problem more intimately.
Have you looked into using free content management systems? I can think of a few good ones:
Joomla
Drupal
WordPress
TONS of others... just do some googling.
Check out this Wiki article: http://en.wikipedia.org/wiki/List_of_content_management_systems
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.