I've recently come across a problem in CSS where I set the min-width property to a certain value that works in Firefox but breaks in Webkit. While playing around a little bit with the Chrome inspector, I discovered the property -webkit-min-logical-width that, when set to a different value than the min-width, fixes my layout issues in Chrome! Does anyone know exactly what this property is supposed to do? I googled for it and didn't come up with anything, even on webkit's website.
EDIT Here's a fiddle demonstrating this in action. View in both Chrome and FF to see the difference. It appears that it may be a min-width override?
-webkit-min-logical-width only overrides min-width when it's placed after it. When in front, min-width is chosen.
This basically makes them equal and my guess would be that -webkit-min-logical-width was the first webkit implementation of min-width. It was a temporary name that still has to work to avoid breaking older websites :).
just my cup of tea :)
EDIT:
this might be it: http://dev.w3.org/csswg/css3-writing-modes/#abstract-dimensions
measure or logical width
A measurement in the inline dimension: refers to the physical
width (horizontal dimension) in
horizontal writing modes, and to the
physical height (vertical dimension)
in vertical writing modes. (The term
measure derives from its use in
typography.)
Do not use it. Non standard and probably deprecated or soon to be removed (see below). Here is the simple definition -
min-logical-width is min-width when the writing mode is horizontal.
min-logical-width is min-height when the writing mode is vertical.
I found the original draft specification revision. If you scroll down a bit, you will find a table that maps the properties to the known properties according to the writing mode.
Also, I believe it is going away soon and will render it completely useless for hacking your CSS for Chrome.
Related
so I've read a lot about the current state of rotating text and not being able to perfectly get real antialiasing to happen in all browsers. It looks like the first box in the pic in chrome, but the second, jaggedy box in firefox. I've tried the most popular fixes including -webkit-backface-visibility:hidden; -webkit-font-smoothing:antialiased; and maybe one other I can't remember.
However this is not asking the same question, but a new one I havent found anywhere. These two screenshots of the same box are both taken from Firefox. The jaggedy box on the bottom is what it looks like normally, however, when I mess with the rotation attributes with another(completely different) element on the page with the css edit console, it renders the box perfect / smoothly...
I do, however, have to continue to press up or down to change the rotation value on another element for the entire box to render antialiased perfectly, then it returns to its jaggedy normal self. I rotated the div that the content is in and put the css fixes on the same div(although I did try putting the css fixes on every element) and I didn't ever seem to get any smoothness or antialising like you see in the box above...only when I rotate another element on the page in the browser. WTF?!!?!? is there a way to do this in css or is it only something the browser is doing in realtime and cannot reproduce that smoothness in CSS yet?
EDIT: PIC for comments section
For whatever reason, it seems under some circumstances browsers "forget" to antialias text while doing complex transforms.
The fix:
Using CSS to force the browser to render the transformed element in a separately-composited "layer" is one solution:
transform: rotate(…) translate3d(0px,0px,1px);
The explanation:
Many rendering engine implementations create a GPU layer for the 3d-transformed element, and composite it onto the rest of the page when painting. This alternate rendering path can force a different text-rendering strategy, resulting in better antialiasing.
The caveat:
However, this is a bit of a hack: first, we're asking for a 3-dimensional transform we don't really want; second, forcing many unnecessary GPU layers can degrade performance, especially on mobile platforms with limited RAM.
dev.opera.com hosts a good discussion of compositing, hacks using transform3d, and the CSS3 will-change property.
Jeremy if you come back and answer this I can give the answer to you. just realized I hadn't had an answer to this so I needed to put something here.
This solution worked as in the comments above:
Jeremy:
I had another thought: it could be related to creating an opengl/webgl layer behind the scenes. If you add translate3d(0px,0px,1px) after the rotate transform, does it "fuzz out" a bit more?
Answer - Yes this works to perfectly anti-alias any text in all browsers!
In days (long past for some, and still present for others) the box-model bug was a bane to their existence. The idea that an element's width included the margin, border, and padding was blasphemous and an abomination to their senses. So we got away from it after thousands of internet blogs about the box-model hack.
Now we get box-sizing, which will, wait for it, allow you to specify that a width contains the border, the margin, and the padding. We plaster a trendy new name for it, "CSS3 Flexbox," and now it's the freedom designers have been looking for.
For those logical people who saw the box-model bug as not the bug and the W3C as the actual bug, this comes as a surprise. A reintroduction of this so-called bug and now we call it an enhancement?
So can someone explain why this is different? I am honestly confused about this.
Now we get box-sizing, which will, wait for it, allow you to specify that a width contains the border, the margin, and the padding. We plaster a trendy new name for it, "CSS3 Flexbox," and now it's the freedom designers have been looking for.
No, we call it the "border box" model. Flexbox is a totally different thing; it is unrelated to the box-sizing property, which is used to tell a browser how to calculate the dimensions of a box.
For those logical people who saw the box-model bug as not the bug and the W3C as the actual bug, this comes as a surprise. A reintroduction of this so-called bug and now we call it an enhancement?
So can someone explain why this is different? I am honestly confused about this.
It used to be considered a bug for a long time because at the time, there was only the One True Box Model (W3C content box model) which everybody had to follow when CSS was just beginning to pick up, and at that time IE was the black sheep. But then people — even those who hated IE's guts — liked this bug, and so border box sizing was added into the CSS3 spec as an option. Plain and simple.1
Note that IE5.x (and quirks mode IE2) will always continue to exhibit buggy behavior as per any version of the spec, and older versions of other browsers that didn't support box-sizing will always follow the original content box model in standards mode (and sometimes, but not always, in almost standards mode).
1 Now there are at least two, the original W3C content box model and the "new" border box model. There's also a third padding box model being explored by Mozilla, but that's not really relevant to what we're talking about here, and it's at risk of being dropped from the CSS3 UI CR anyway.
2 Depending on whom you ask, this may be regarded as a "feature" instead, as the primary purpose of quirks mode is to emulate buggy browser rendering for use with legacy code, and it is not intended for use with new code.
I have been working on a little photo slider. It looks slightly different in Chrome than in FF so I thought a CSS reset would make them both look the same. I used the Yahoo! YUI CSS reset model but nothing changed. It looks good in FF but in Chrome the "Resume" button on the right side sticks up too high and a thin gray line at the bottom of the big pictures gets cut off where the main buttons are located. Here is the URL:
http://www.replayground.com/slider/02.html
You can ignore the stuff below the circles. Just testing stuff down there.
Here is what I added to my 02.html file:
<link rel="stylesheet" type="text/css" href="http://yui.yahooapis.com/2.9.0/build/reset/reset-min.css">
I'd really like advice on how to get CSS Reset working correctly. Not how to fix the specific buttons problem you see. As I add elements to the page I don't want to have to go through this each time.
A CSS reset is not designed to make all the rest of CSS cross-browser. It is designed to set all of the client default rules on all the different browsers to the same thing so that you are always working from a predictable set of CSS rules. How the browsers interpret those rules is still specific to each one.
In your case, you still need to figure out how to write CSS rules that operate the same in both Chrome and FF - the reset simply levels your starting point a little, it doesn't remove the browser rendering differences.
You may find a cross browser CSS framework (e.g. blueprintcss.org or 960.gs) to be more helpful for your current situation. They often use a reset, but also have rules that compensate for the differences in the rendering of the after-reset CSS rules.
jball is very right about the resets. They just allow you to start with a blank page, but you should still write a proper document structure and good CSS to get good and consistent results.
In your case, all elements in your page are loose in the page. This will give you trouble in the end. Some things will shift a few pixels, especially when you don't specify exact height for every item. Fonts are rendered in different heights by each browser. These may be tenths of pixes, but when they get rounded, your website is a little off between browsers.
When you use a little deeper nesting of elements, you can make better use of positioning elements (relative and absolute). If you put in a specific div for the header, and give it a fixed size, you can position each element in there very precisely, which is especially handy for headers and menu's.
I took the liberty of creating a small example, which shows just some basics of positioning. It is not perfect and uses brightly colored borders instead of images for the layout. But it's just for showing the element nesting and absolute and relative positioning, along with a negative margin trick.
http://jsfiddle.net/YwCxQ/3/
I have a Blogger template which is wider than the screen-width and causes the horizontal scrollbar to be displayed. I want to change it so that it fits and no scrollbar is shown. But the problem is I don't know what is causing this. I have downloaded the template file and in my code editor looked for all width properties and changed all 100%s to 90% and pix width values to value-100, but still the page is as before.
In finding the effective rule/rules in a such cases, what else should I look for/do? What is a comprehensive procedure to check things to find the rules?
Instead of changing the width, try adding the CSS property overflow: hidden to everything you think might be causing the issue and then remove them one-by-one until the scroll bar reappears and you'll have the culprit. You might need to add it to html and body as well. If the scrollbars aren't revealing any actual content, you can leave the overflow: hidden on the culprit to resolve the issue.
It might not be a width property that's causing the problem - there might be a block element inside your template that doesn't wrap or float that might be stretching out your container if the widths of the containers are defined using percentages.
Define the root container using a fixed width and this should eliminate many of those sorts of issues. Try that first and let us know if it works.
Procedure:
1). Understand the box model and how this varies on IE. It is just as likely that a problem "width" may actually be caused by padding, margin, or even border as width.
2). Check the rendering in other browsers. If you can reproduce the problem in FF get Firebug and use that to find out the calculated dimensions of the element in question, and tunnel down through it's children which may well be causing the issue. Chrome has a similar debugger to Firebug iirc, but I'm not familiar with it.
3). If that doesn't tell you what the problem is, start removing rules or whole patterns from your CSS until the problem goes away (or remove everything and add it back in piecemeal until the problem returns) - at that point you know what is causing the issue, if not why, and you can always update the question to ask us why when you've identified it.
hth
(Apols if any of this was already obvious)
Well, % always begins with "100". See the percentage of width of body tag is set to 100%. then according to it, just set other component % as per the requirement in your display.
Personally I do believe that, use of % is better then 'px'. If you know CSS, then try to change 'px' to % as per the requirement.
It seems that the component has min-width style and overflow property set to auto. You may want to set it to visible and do it in FireBug Firefox Page Inspector first, to see the effect alive before making post edit. If you just want to adjust the whole post width, blogger has standard interface. You can also edit the template manually
How do other designers normalize padding and margins across browsers. I have tried CSS Resets (currently using the YUI one), but I still run into a lot of inconsistencies.
It seems for some elements, with some browsers, setting a padding or margin to 0px will trigger the browser to use a default padding and margin determined by that browser. Is there a way to hard reset the padding or margin across all browser so there is a consistent look?
Update
It seems from additional research and the feedback here, it's near impossible to get websites to look the same across different browsers to the letter. I think I'll stick with using a CSS Reset and just try to plan out my sites better.
I'm not sure how to overcome the default browser mechanisms that override style settings and it would probably be too much effort to do so.
This is usually solved with a CSS reset but not all of them are complete. On some browsers, the overall body has to have its border set to 0 (i.e. Opera and sometimes IE) to be truly the same. Try the following:
body,html{margin:0;border:0;padding:0;}
Since you don't say which element or give a link I can't really go too far into this. Which elements are you having trouble with?
Its not worth the extra CSS interactions and extra code to add a complete set of "normalizing" padding or margin elements.
Its best to style for what you need by explicitly stating the padding and margin for the elements you are using on your pages.
Paddings are usually 0 everywhere. It are the margins which are the most disbalanced among browsers. Just define your own margins on HTML block elements. A CSS reset is like a sledgehammer. You'd need to redefine more than only margins. But it may be helpful for beginners since they often can't at first glance distinguish between default inline and block elements in HTML. A CSS reset would force them to redefine the one and other "the right way".
Related questions:
Are margin and padding the most disbalanced among browsers?
That said, if you keep seeing inconsistencies among browsers, then it may happen that you're using a doctype which forces the browser into quirksmode. In MSIE the box model bug would then come alive. You'd like to use a strict doctype: <!DOCTYPE html>.
See also:
Activating browser modes with doctype