Want to know whether you can use CSS Grid Layout (or any other CSS feature for that matter) in a specific browser?
Go to:
Want to know whether you can use CSS Grid Layout (or any other CSS feature for that matter) in a specific browser?
Go to:
margin is the space around elements (i.e. outside the border of an element).
padding is the space between the element border and the element content.
Visually, this helps:
The four numbers you may see after each of these start at the top and then go clock-wise. E.g. this:
margin:25px 50px 75px 100px;
means that the:
top margin is 25px
right margin is 50px
bottom margin is 75px
left margin is 100px
Note that the word “auto” is an instruction for the browser to calculate the margin.
The number of arguments to margin can vary from 1 to 4. Here’s what to do for the various cases:
One single value applies to all four sides.
Two values: apply first to top and bottom, the second to left and right.
Three values: apply first to top, second to left and right and third to bottom.
Four values apply to top, right, bottom and left in that order (clockwise).
More info here:
http://www.w3.org/TR/CSS2/box.html
and here:
https://developer.mozilla.org/en-US/docs/Web/CSS/margin
And this lets you actually try it out:
Here’s how to cache CSS / PNG files.
1. Use Expires caching headers
i.e. rather than Cache-Control – see:
https://developers.google.com/speed/docs/best-practices/caching?hl=sv#LeverageBrowserCaching
2. If you’re using Apache these are set in the httpd.conf file:
e.g.
<IfModule mod_expires.c>
ExpiresActive On
ExpiresDefault “access plus 10 days”
ExpiresByType text/css “access plus 1 week”
ExpiresByType text/plain “access plus 1 month”
ExpiresByType image/gif “access plus 1 month”
ExpiresByType image/png “access plus 1 month”
ExpiresByType image/jpeg “access plus 1 month”
ExpiresByType application/x-javascript “access plus 1 month”
ExpiresByType application/javascript “access plus 1 week”
ExpiresByType application/x-icon “access plus 1 year”
</IfModule>
http://css-tricks.com/snippets/htaccess/set-expires/
3. If you’re on a Dreamhost VPS the httpd.conf file is here:
/dh/apache2/apache2-ps<your-number>/etc/httpd.conf
To access it use:
su – <your-admin-user>
and restart with:
sudo /etc/init.d/httpd2 restart
4. And you can test how successful your updates were here:
By default, Rails assumes your assets are precompiled in the production environment.
And this gives you the best performance.
To check, config.assets.compile should be set to false, e.g.
# config/environments/production.rb
…
config.assets.compile = false # don’t compile at runtime. i.e. assets are precompiled
However, you will need to make sure your assets are precompiled. e.g.
bundle exec rake assets:precompile
A bit of a pain if you have to do it manually. Fortunately, Capistrano has a recipe to handle this at deploy time.
Notes:
1. you can disable the asset pipeline while creating a new application by passing the —skip-sprockets option
2. You must have an ExecJS supported runtime in order to use CoffeeScript
More on the Asset pipeline here:
Say you’re interested in ONLY debugging some SQL.
But your rails console is spitting out GETs for assets.
Here’s one way to disable logging of the asset pipeline. Place the following code in config/initializers/quiet_assets.rb
if Rails.env.development?
Rails.application.assets.logger = Logger.new(‘/dev/null’)
Rails::Rack::Logger.class_eval do
def call_with_quiet_assets(env)
previous_level = Rails.logger.level
Rails.logger.level = Logger::ERROR if env[‘PATH_INFO’] =~ %r{^/assets/}
call_without_quiet_assets(env)
ensure
Rails.logger.level = previous_level
end
alias_method_chain :call, :quiet_assets
end
end
Also works with Rails 4 (although you need to create the file).
See also:
and a possibly better way via a Rack middleware:
https://github.com/rails/rails/issues/2639#issuecomment-6591735
Note, in development.rb there’s a
config.assets.debug = true
which you can set to false. This reduces most of the 304’s for the asset pipeline but you still get the application css and js files being logged.
Obviously another way of doing this (and possibly the easiest) is to just do:
tail -f development.log | grep -v “asset”
Very handy for live editing of HTML, CSS and JS.
Not only that – you can share the code to other people for them to edit simply by sharing a link!
Great article:
The Metrics side panel shows 4 bits of information. E.g. in this screenshot:
The perimeter of each of the four areas is called an “edge” so each box has four edges.
Reading from the inside out:
1. Content edge: 1400 (width) x 52 (height)
This surrounds the rectangle given by the width and height of the box. It’s the intrinsic size of the content and often depends on the rendered content.
Padding edge (optional): 0
This edge surrounds the box padding.
Border: 0
The border edge surrounds the box’s border. If the border has 0 width the border edge is the same as the padding edge.
Margin: 80 (top and bottom)
The margin edge surrounds the box margin.
More information:
Box model:
http://www.w3.org/TR/CSS2/box.html
Visual formatting model details:
http://www.w3.org/TR/CSS2/visudet.html
Inline formatting mode and the rules laid out in CSS2:
http://meyerweb.com/eric/css/inline-format.html
Chrome is fast.
And DevTools are powerful.
So, makes a great combination for debugging HTML / CSS. Launch it by going to the Hotdog menu > Tools > Developer Tools or Alt Cmd I.
Switch between tools with the keyboard shortcuts: Cmd [ (left) or Cmd ] (right).
These tools are:
1. Elements: inspect and edit the DOM tree
2. Resources: inspect resources in the page. e.g. HTML 5 Database, Local Storage, Cookies, AppCache, etc.
3. Network: inspects network resources in real time.
4. Sources: debug JavaScript
5. Timeline: time spent loading or using the web page
6. Profiles: profile execution time and memory usage of a web page
7. Audits: analyze a page as it loads and provide suggestions / optimisations for decreasing load time
8. Console: the JavaScript Console lets you log diagnostic information and offers a shell prompt
window.onload used to be pretty accurate.
But now we’re lazily loading stuff, using responsive images, dynamic elements rendered with JS and CSS. So, it’s not an accurate guide to user perception. E.g. take Gmail.
This isn’t ready till after window.onload. But there’s nothing that can tell us it’s ready.
Or Amazon.com, it’s usable (i.e. we can see products and prices) after around 2.0 seconds but the window.onload doesn’t fire till 5.8 seconds.
Which is the reasoning behind Speed Index at Web Page Test.
http://marakana.com/s/post/1432/how_fast_are_we_going_now_web_performance_Steve_Souders_video
See also: