Link or Embed CSS

[williamsun]

All things considered, which way is better, linking the css or embedding it?

I always thought it was better to link css style sheets to take full advantage of the cascading feature, but I see a lot of sites that embed all the css -- forcing small formatting changes to be done to every page. But they still do it anyhow. There must be a good reason.



I don't know if this has been covered, I couldn't find it with a forum search.

[jscheuer1]

Embedding styles is inefficient and indicative of a poor overall concept and/or an unwillingness to adhere to it.

It's often easier in the short term though, so it's always tempting.

There are rare cases where it might be unavoidable, but these are generally much less than people who resort to it a lot might imagine.

[williamsun]

The only reason I could come up with is maybe some people disable styles/linked extras as an extra security measure against hacker's cross site scripting exploits (although that really isn't the way it works). Whatever the reasons maybe they just want to make sure that the formatted page is delivered to the site visitor. -- That's all I can figure, but I need to consider every possibility because without the linked style sheets my site looks like scrambled garbage.

[djr33]

If CSS is disabled, it won't matter where it's from.

It's easier in a lazy sense to embed the CSS, but then as you know well it's much harder to maintain the site.

It's useful to put specific styles for one specific page within the HTML as embedded styles. This is especially true if you might be generating them dynamically such as with PHP or another server side language.
[Note: it IS possible to generate a dynamic serverside-controlled CSS file, but it's much harder than the average PHP/etc user would be able to handle. It involves .htaccess and/or sending headers to explain what the file is for. It's just plain text as content, so it's possible, but it's difficult. In the same sense, PHP can generate images, but it's not easy to do.]

But if you're creating styles that aren't meant to be shared between pages, it's all but crazy to not create an external stylesheet.


My guess is that those pages you found with the embedded styles either:
1) Are generated dynamically with serverside languages like PHP (so the CSS is in fact stored in one place). This is only inefficient in the sense that it is sent to the user each time the page loads, so it's a little slower and takes more bandwidth. For site maintenance, it's not bad.
2) Are just badly designed sites.

[williamsun]

Ok, I didn't say it was the right thinking, just my thinking. lol

Thanks to the both of you for your responses. They might have been php pages, I don't remember. Is there any kind of search engine advantage or any other advantage to having php pages, besides the php programming itself (which I can't do haha) and being able to insert duplicated items/modules/blocks? I have often wondered that.

I have never had a web or graphics class so I'm clueless about a lot of things. lol

[djr33]

PHP is useful for the designer because it allows automation of HTML and using elements across pages, actually very similar to external stylesheets for CSS. It also allows databases, form processing, sending emails, etc.
But no, PHP doesn't do anything for search engines. Search engines (and visitors) end up seeing plain HTML pages (even if they are labeled "page.php") as if they were written by hand. PHP operates entirely and only on the server then sends plain old HTML to the user.

[keyboard]

If embedding css is generally "frowned upon", then why does vbulletin do it?

[williamsun]

If embedding css is generally "frowned upon", then why does vbulletin do it?
PHP like Djr33 was talking about. PhpBB is the same way.

[keyboard]

But you can have a .php file which (with the right header) can be used as a .css file... same for .js

[williamsun]

He explained that the linked pages are delivered to the user in one page. If you view source it is all in the page you see, but on the site they are different css pages.

[djr33]

Forums like this usually have an admin control panel where styles can be edited. It's much easier to do that with content in the database rather than editing a .css file directly, especially when the final CSS is a combination of several components. And that way it can serve only exactly what is needed on one page, no extra styles.

Yes, it's possible to dynamically generate a CSS external file (either with .css if you can change settings on the server perhaps via .htaccess, or as .php with modified headers) but because forum software is designed to be distributed across various servers, compatibility is important so risking that it might not work on one server or another is probably why they avoid this. It's also more work. But you're absolutely right-- the best way would be to work out the bugs and use this method.

The only true argument for embedding versus external CSS would be to have specific CSS for only what is on the page. For one page (or even a few) this might save some space rather than downloading all of the CSS for the entire site. But if you do load many/all of the pages, it ends up being counterproductive because the external file doesn't need to reload each time. Additionally, you can increase efficiency by having several different external stylesheets-- one for the whole site (shared elements, general settings like font), and others for specific pages and/or sections of the site.

[williamsun]

PHP is useful for the designer because it allows automation of HTML and using elements across pages, actually very similar to external stylesheets for CSS. It also allows databases, form processing, sending emails, etc.
But no, PHP doesn't do anything for search engines. Search engines (and visitors) end up seeing plain HTML pages (even if they are labeled "page.php") as if they were written by hand. PHP operates entirely and only on the server then sends plain old HTML to the user.
One other thing that gives me pause, is with more and more people designing mobile friendly versions of their pages, would converting pages to php be beneficial to cut down on coding of a "second mobile version" of every page by using the 'include' to only include the important parts of pages in the mobile version, or is it better practice to use css to display certain IDs & Classes from the original version of the page?

[jscheuer1]

Generally you are better off having only one page per page and just using javascript and/or css to make it workable in all the various devices you want to support.

But it can get extremely complicated. When it does, you can simplify the page - a sort of lowest common denominator approach, or serve a completely different page to one or more devices or class of devices. That's also pretty complex though, so I would advise simplifying the page as much as possible.

One nice thing with includes is that if you do have two pages, one for laptops and desktops and another for mobiles and other touch devices, you can use some of the same includes (those representing raw content and/or even styled or scripted content that is cross platform) for both.

[williamsun]

One nice thing with includes is that if you do have two pages, one for laptops and desktops and another for mobiles and other touch devices, you can use some of the same includes (those representing raw content and/or even styled or scripted content that is cross platform) for both.
Yes, that's kind of what I meant. Because I have media/youtubes/photo gallery I need to start considering going mobile friendly. For me the issue converting to php is viewing locally while editing instead of edit a little, upload, view, edit a little more, upload, view, etc. I don't want to install a php engine and a web server on my pc, so the only solution that "I" know of is to temporarily use the .htm extension while editing (minus the 'includes') then converting back to php when done. That seem awful clumsy though. If it wasn't for that, I would have converted to php already.

I may end up just doing it with css to display a smaller background and display:none; for the unnecessary blocks and just show the important div wrappers. But that may end up being tougher than just converting to php and using includes.

[jscheuer1]

It's tough right now with media (includes sound and video, some others). IE 8, still in wide use doesn't support the new HTML 5 media tags (audio, video, poster, perhaps others). The browsers/devices that do don't all do it the same way. However there are plugins that do most of the 'heavy lifting' for you showing Flash based solutions to browsers that require and/or do better with it and media tags for the rest, each in a way it can handle. Media tags BTW are generally more efficient.

Going forward, media support will become more standardized, it's just a matter of time. Older browsers that don't support the new media tags will fall further into disuse, and those that do support them will become more standardized in that support.



Working with PHP is virtually impossible without a localhost PHP server like WAMP or XAMP. I mean you can do it, but it's as you say - a real headache. These packages are available for free, and although they do require a fair amount of resources to run, they shouldn't crash your computer and can be turned on and off fairly easily. So you should be able to use them only at times when the resources needed are available. I often have 3 or more browsers open, sometimes with a virtual machine with one more browser in it. Opening the localhost server at that point, while connecting to a live server via ftp at the same time, well at that point I'm on thin ice. Throw in a Skype to Skype video call, and it's reboot city if you know what I mean.

So when I'm working with the localhost server, I try to only have like 3 or 4 browsers open and no other applications like the virtual machine, Skype, or live ftp that needs those type of resources. Applications which require control of a port are particularly problematic if run together. Each port takes up resources, and if two apps want the same port, that's trouble. Localhost server, Skype, ftp, each require control of a port. Browsing the internet, passively monitoring for updates, etc., the normal connectivity all computers usually have these days requires one as well. That one is usually shared among those activities. And the virtual machine uses one or more if it's doing one or more of those things.



Image galleries can generally be cross platform if they're javascript and/or css based. But some advanced features/effects will either have to be optional or skipped to get them to be truly cross platform. Look for ones that rely solely upon click actions to perform, or that will degrade nicely when click is the only action that can be employed.

[williamsun]

However there are plugins that do most of the 'heavy lifting' for you showing Flash based solutions to browsers that require and/or do better with it and media tags for the rest, each in a way it can handle. Media tags BTW are generally more efficient.
Can you expand on plugins and media tags.


Image galleries can generally be cross platform if they're javascript and/or css based. But some advanced features/effects will either have to be optional or skipped to get them to be truly cross platform. Look for ones that rely solely upon click actions to perform, or that will degrade nicely when click is the only action that can be employed.
My photo gallery at present is flash, and I'm trying to learn flash, but my version is prehistoric Macromedia Flash MX (2002). I'm hope the same tweaks I may do for youtube videos and such, would work for it too.

Do you consider flash to be fairly cross-platform stable and even preferred?

[djr33]

One other thing that gives me pause, is with more and more people designing mobile friendly versions of their pages, would converting pages to php be beneficial to cut down on coding of a "second mobile version" of every page by using the 'include' to only include the important parts of pages in the mobile version, or is it better practice to use css to display certain IDs & Classes from the original version of the page?Yes, that's a good strategy. John is also correct: having a single version of the page that can be displayed in several ways on different devices is a good idea. But if you need to generate multiple versions of the same content with different HTML code, then PHP (or a different serverside language) is the solution rather than rewriting it constantly. You'd use a database and import the content into two PHP template pages.


Do you consider flash to be fairly cross-platform stable and even preferred? That's very hard to answer. At this very moment and in the past, yes. But Flash is specifically [intentionally] not supported on Apple mobile devices (iPhone, iPad) and it may not be available on all systems. It's better than any other plugin (for example, Java or Silverlight), but that doesn't mean it's a perfect solution.
Up to this point in time, it was the best solution. But now HTML5 audio/video is replacing it. The problem is that it hasn't replaced it yet. Not all browsers can handle HTML5 audio/video. So the best solution is to use a mix, allowing for Flash or HTML5 depending on which the browser supports.
As an example for audio, I use (and like) this script:
http://www.schillmania.com/projects/soundmanager2/
It plays with Flash or HTML5, whichever works. It works on iPhones, old Flash-only browsers, etc.
For video, it's trickier and I'm not sure. Beyond this, the second problem is file formats. Flash supports flv/fla and mp3, while many browsers do not support either with HTML5. So you often would need to create two (or more) versions of the audio files (and video might be even more complicated).

--Right now: Flash will give you the best results immediately, but it will miss several (probably important) groups of visitors including Apple mobile devices.
--For the future: HTML5 should become more and more supported to the point where Flash is no longer needed. This will take a long time-- years (2? 5? 10?). And users of old browsers won't ever be able to use it until they upgrade, from IE6 to IE9, or whatever the case might be.
--Most effective solution: use a mix of both; but that's complicated.

[williamsun]

Then what does iPad & iPhone do to view youtube videos and simlar content?

[djr33]

Apple mobile devices have a youtube app that works for only youtube videos (not other video sites). It's not in the browser, but it plays youtube videos that way. Instead of an embedded youtube clip, the youtube app opens from a link on the page. It's similar to downloading content on a computer, except that on the iPhone it still would be streaming.
They also have HTML5 audio/video.

But they cannot otherwise use Flash or Flash-like content.

[williamsun]

Ok, thanks. This is an extremely informative discussion for me.

[jscheuer1]

You were asking for more information on media plugins. This is my current favorite:

http://jplayer.org/

There's a bit of a learning curve. But it's free, and as I mentioned before, most of the 'heavy lifting' is done for you.

[williamsun]

That looks good. I will explore it more and prolly include it when I start creating mobile content.

Thanks

[williamsun]

You were asking for more information on media plugins. This is my current favorite:
http://jplayer.org/
Have you checked out JW Player?
http://www.longtailvideo.com/players
One of the pro sites I visit often uses this one. I don't know how flexible it is.

At some point I want to use one of these for a master player with a list youtube & vimeo links to play in it, instead of a long page of youtube iFrames.

[jscheuer1]

Yes, but it's not free. I'm not sure if it's all that much easier to use than the free code I linked to. It should be though if you're paying for it.

BTW, Vimeo has an iframe interface very much like YT does. So, if you're only showing Vimeo and YT video, those (embedded as their service's respective iframe embed codes) are already cross browser/platform.

Making a playlist of those is doable but tricky. The feature set is more limited than with the object/embed methods those two services offer. You could use an iframe and load each video's iframe, each from a separate page into it via links. That would probably be the simplest.

[williamsun]

What I saw was an open source free regular version, and they also had a Pro version that was paid. But ok, I'll keep that in mind. I was thinking of trying to work a single player instead 10 - 15 YT iFrames on a page. Ok, it's prolly not worth worrying about. Thanks.

[jscheuer1]

The free version of a paid program almost always is crippled in some way and/or branded. They're trying to sell you the paid version. If you can live with that, fine. I generally prefer to use the completely free version (like the one I mentioned) even if it means a little more work is involved.

[williamsun]

I used the YouTube APIplayer that Molendike used in this (http://www.dynamicdrive.com/forums/showpost.php?p=277644&postcount=12) thread and it worked perfectly for what I wanted. It even plays Vimeo vids in Firefox and IE. I added a regular YT iFrame to the Video Container on a lower layer to display a default video that can be clicked on and played. Clicking one of the links replaces it and plays that way. Close the video window and it's empty. Refresh the page and the default movie shows again. It's awesome. Thanks Molendijk

[jscheuer1]

Great!

[webstepa]

thank you for sharing