In AEM, I see that its good to make the header as an experience fragment that making it as a component. Any reasoning for that?
Both are valid. But the reason the Experience Fragment method is better comes down to a few things:
Fewer components, reuse of existing components.
Changes to the header and footer may be accomplished without the need for development
The header and footer are self contained and could be queried for use outside of AEM if necessary.
Experience Fragment variations allow you to create different header/footer options for various scenarios, but keep them in one place that is easy for authors to understand.
Related
There is a way to remove unused css with uncss https://github.com/giakki/uncss
And an excellent blog post on the subject: http://addyosmani.com/blog/removing-unused-css/
However I fail to see how you would combine this approach dynamic content (for example generated by angular directives or async page loading) which will be missed by the uncss module.
Is there an optimal way to achieve this, I'm not wanting to manually go in and remove all the bootstrap css I'm not using.
My best recommendation would be to create a couple of static pages with examples of all of the markup you anticipate needing, and run uncss against that.
Even if the content is dynamic or asynchronously loaded, you should have a pretty good idea of what content is possible.
For example: you're probably very likely to need basic text formatting, headings, rich text content, lists, links, pictures, etc. Depending on the subject of your site, you'll also know whether you need to display code samples within <code>, <kbd> or <pre> tags.
However, it's not as likely that dynamic content would directly need to utilize the grid / layout system on its own, or would require any extraneous button styles.
Build a test page that includes everything you anticipate using. If you know there's something you want to keep, then throw it in. Otherwise feel confident knowing that uncss is doing it's job cleaning out everything else.
I am developing a chrome extension that is meant to work on all web pages. As part of its functionality, it needs to show a UI on any given page.
Currently, to do this, I append a div (containing the UI HTML) to the page from the content script. The issue with this is that the styles of the containing page get applied to the extension's UI, causing it to look different on different webpages.
Two approaches to fixing this issue:
Apply specific styles (marked as !important) for the extension's UI elements. This is really hard because depending on the page, any attribute of any element can have a different value.
Add this UI to an iframe, and insert that to the page. This of course, fixes the CSS issues with approach 1. But I haven't worked much with iframes in the context of extensions before and I'm wondering if there are any concerns that I should be aware of.
Some of the potential issues that come to mind:
1. There can be complexities in the content script interacting with the iframe js.
2. Some users might have iframes disabled at the browser level for specific or all sites?
Generally, the use of iframes is frowned upon, for reasons of security and performance (among others). I am wondering if in this scenario, using an iframe is the most sensible option?
Also, I intend to port the extension to Firefox later. This is probably not relevant, but just putting it out there in case it helps tilt the decision.
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.
Our Dev team had been developing enterprise web page more than 2 years ago. We are curious to know what is the best way to write a contract for CSS usage. For example, if we have a COMP, how we agree on a contract so our developers and our designers agree and we don't have to go back.
Is there a tool that is available for this type of technical writing?
What is the threadhold of information put in the CSS versus on the HTML page? Some of our designers thing that some things should go directly into the HTML page. The general opinion is that everything that is style should go in a CSS and all else in the html.
Thanks for your input.
Well, if a webpage has very specific CSS just for itself, I guess there is an argument for defining the CSS in the page, otherwise I would always have the CSS in an external file.
Try to avoid or at least minimise in-lining the CSS as a style attribute on HTML elements though, that would be a PITA to manage.
Most pages will be template driven with standard content styles, and thus the CSS styles will be defined in external files.
One thing you might want to think about are the number of CSS files - some people suggest that you should minimise this to just one file site-wide or per-template (or area of the site) to minimise HTTP requests to the server and avoid delayed CSS loading and funny looking styling up until that point.
So this "contract for CSS usage" is actually just a coding standard for HTML pages?
I'm a purist, so for me HTML is for content and structure and CSS is for layout & styling. That's really what each of them were created for.
See CSS Zen Garden for a great example of this. Same HTML and hundreds of different layouts & designs.
What are the reasons your designers give for styling to be in the HTML?
Edit: The main goal here is consistency across the site, correct? The more you have abstracted away from each page, the fewer changes you'll have to make.
The idea that the HTML should merely encode information and not style is called semantic markup. It has several advantages that you already know about, like separation of concerns, and a few that you probably haven't thought about.
If you stick to the web standards and separate your style and content you will also end up with a page that is more accessible to those with disabilities.
If you need to have some things styled differently for a specific page, use separate CSS include file for that page only and then use a CSS class on the element you want to style.
If I have style that is for a one time, single use page, I will consider putting it in the header of that page, as my templating system allows for that.
However you should never use inline styles. Even if you do a page with a block in it for a one off. That way should you find that you "one time" item becomes a site wide style, you can simply move the CSS into the external CSS file and not edit the content.
Looking for some direction here as I'm running into some migration problems.
We have a legacy application. The 'infrastructure' is running just fine. Business logic and data access layers written in VB calling SQL Server for the database.
I have a LOT of experience writing Winforms (desktop) application and have had no problems. However, the last time I wrote any ASP.NET stuff was in 1.1 (VS.NET 2003).
Among other things, for ASP.NET 2.0 and up, the Grid layout is gone. It's not just a simple case of dropping controls on a form, aligning them, ordering them and working with the code-behind anymore.
The new web-based application is starting out pretty simple. Just a common header (already made a user control for that) and footer with your typical CRUD functions in the middle.
I tried being 'intuative' in using a master page with content place holders but I couldn't get the placeholders to "grow", to say nothing of not being able to put a text box where I wanted one. Oh, I found the option in VS2008 to allow absolute positioning but it only worked for SOME controls - others I had to manually edit the asp tags.
Then I saw examples using div's and tried to implement them but I ended up with results that had objects writing on top of each other. The online help wasn't helpful to say the least.
Does anyone know of a good book, website or tutorial that can give the basics of what I'm looking for? In practice, I'm looking to make simple pages where some objects may have to push others gurther down the y-axis (as in, several comments being made and that section would push the section listing the 'attachments' down further). I have no trouble when it comes to all the other aspects of this application. It just appears that my webforms skills are about 3-4 years out of date.
This isn't going to be some fancy flash/silverlight application - just simple 'data maintenance' to get rid of some ugly and bug-prone processes involving reading common mailboxes and decoding Word files. The new goal is to have a nice weborm with proper validation.
I guess what I'm looking for is a "Webforms for Winforms programmers" book or site.
Help!
Thanks in advance.
The best advice I've heard on learning to use html/css layout goes something like this:
When building a new page, don't try to get all fancy up front. Start by building a very basic, text-only page. It should look like something from 1996- that brief period where everyone had just discovered the web but had not yet started using the table tag for layout- only no comic sans font. Don't use images at this point, unless the image is genuinely a part of the information being conveyed (as opposed to the window dressing to make it look pretty: you can add those later). There will likely be an h1 at the top of the page, and give each sub heading an appropriate hN, but at this point there shouldn't be any layout information in the page at all. The only place you'll have a table tag is if you genuinely have tabular data to show. If it helps you write this code then you can wrap everything in old-fashioned <center> tags for now- just don't forget to remove them later.
Now let's start tweaking the markup a little. Use things like ul (unordered list) for your list of navigation links and label/legend to identify and group your form areas. The general idea here is to have each element on the page encased in the most appropriate html tag, and to use the full set of available tags- each for it's designated purpose.
At this point you have a page that is ideally suited for a screen reader or search engine. By building this page first, you have made SEO and accessibility compliance easy on yourself. Of course those aren't the only requirements, so we're not done yet.
Now you need to identify the different sections of your page, from both the layout and logical perspectives. The page should largely already be divided logically, but you may find a few places where the normal tags don't cut it. You'll also want to group certain elements for layout reasons. Encase each of these areas with a div tag, and give the tag a class name that refers to the purpose for the tag: the group your are creating. This is just another case of using the a tag (the "division" tag) for it's intended purpose. Also, since elements can have more than one class, you may want to think about also grouping your classes logically. For example, you might want to have a separate class that distinguishes the site template from the rest of the page.
By and large this should not have changed the appearance of the page, but now you have something where it should be very easy to start adding styles. At this point you can now start adding images and layout. The goal here, though, is to change the actual markup as little as possible. If you can manage it only add ids and classes, though you will likely need to add an additional span or div that you had not identified earlier, and sometimes you'll need an extra block level element to force a compatible layout across browsers.
If things are done correctly, the result is a page that not only looks good, but is also easier to work with when testing across browsers, will naturally degrade well when a style or javascript feature isn't supported, and scores well for SEO and accessibility. This also makes it easier to have a developer build a simple page that provides a certain level of functionality, which they can this pass off to a separate designer to make it look good.
You may also want to check out A List Apart. This is a great website with lots of "tricks" for using CSS to layout things on the web along with lots of other web oriented content.
Grid positioning was an abomination for websites. Sure it made for an easy transition from those familiar with the WinForms designer, but it produced horride HTML that is nearly impossible to maintain.
The very best resource I can recommend to you is CSS Mastery. You'll need to learn HTML and CSS, but they're quite easy to get into.
By the sounds of it, you're looking for a crash course in HTML ?
the "Design Canvas" of an ASP.NET aspx Page & ascx Control is just HTML tag markup.
If you've no web design experience, I'd recommend starting somewhere like
W3Schools
When Microsoft gave us ASP.NET, they tried to make programming websites, more like programming rich client applications. However, there are a lot of issues you have to deal with, the major one being statelessness, when developing for the web that don't exist when developing a thick client app (WinForms). So the first step is to not think of the two as similar in anyway.
The drag and drop tools are nice, but what you really need to understand is HTML and client server models. HTML will help you understand how things are getting laid out, and client server models are important to understand how data gets to and from the web to the server. If you have developed in ASP.NET 1.1, then things really haven't changed for 2.0. The concepts are the same, just some of the provided controls have changed.
A lot of people were really unhappy with the grid-based layout from 1.1, because it didn't really work in a number of situations. It still has to ultimately render as html, and html just isn't suited to that kind of layout. For example, things might not be ordered properly or pushed off the screen for mobile browsers (iPhone, etc). There's also things like screen readers for the blind. If you work for the government, that 2nd item is a legal requirement rather than just a nice-to-have, and there are a lot of developers who do work for the government.
So ASP.Net 2.0 tried to generate markup that's at least a little nicer for html. The downside is that you actually have to understand html layout now. But, c'mon: you're building a web site. If you can't handle a little html you're in real trouble.
My advice to build one static page using something other than visual studio. Use <input tags rather than server controls on that page and don't actually implement any logic. Use it to understand how your layout will need to work. Once you have that down, it's really easy to duplicate that for your pages in Visual Studio.
This doesn't really belong as a separate answer, but I wasn't sure you were likely to see another comment to my response above.
The normal behavior of all block-level elements, including divs, is for each new element to appear below the previous element. It sounds like you've set position:absolute; on everything, perhaps while playing with the Grid-based layout option in visual studio. Don't do that- it's hijacked the expected behavior and that's why you see everything piled on top of each other.