Is this going to cause me untold grief if I stick it at the top of my stylesheet?
* {position:relative}
Is this going to cause me untold grief if I stick it at the top of my stylesheet?
Yes. You will not be able to work with absolutely positioned elements any more, for example - the absolute positioning will always be relative to the parent element, which is almost never the desired result.
I could imagine there are even more side-effects field of z-index settings.
Not a good idea IMO.
And no, position: static is not deprecated, after all, it is the default setting :)
Wildcards can cause performance issues when not used carefully. That would probably not be the case in your example, but it's a bad habit to develop.
But more importantly, it's rare that you can conclusively say you want any behavior to apply to all elements.
With relative positioning, you will at best achieve nothing and at worst create many headaches for yourself trying to troubleshoot things that would normally "just work".
Relative positioning definitely has its uses. Apply it when you need it.
It's a bad idea imho as it changes the default behaviour of elements without clear indication and it will have unforseen consequences.
If you really want to have most elements positioned relative, you might want to think about just making div and similar relative.
Just to give the other side of the coin, I have used this setting quite a lot, and have found it useful. Main advance being the easiness of using positioning properties (top, left, right, bottom) without having to define relative positioning to parent all the time.
It's true that this setting will make it impossible to use absolute positioning in relation to anything else than the parent right above, but I find this to be a good thing. Because the first parent with 'position: relative' is visually de facto parent of any child with 'position:absolute', then it is only logical to make them direct children also in the HTML hierarchy.
In short * {position:relative} forces a convention that makes it easier to reason how positioning works.
Caveat 1: Event if the new convention simplifies things to new comers, it's different from what seasoned CSS developers are used. Prepare to face opposition if you start using this in big project with many frontend developers.
Caveat 2: Performance issue should be tested properly. I have tried turning this setting on and off on some big sites without noticing any difference, but no real tests with real numbers exist (to my knowledge).
Final note: First line in the second paragraph is not quite true. You can always overwrite wildcard definitions, setting position: static some mid level node, if you really need to.
Answering title question:
This is the current CSS 2.1 spec:
http://www.w3.org/TR/CSS2/visuren.html#propdef-position
Accepted values include static, relative, absolute, fixed and inherit.
I'm not sure about CSS 3 (it's still work in progress) but they don't seem to mention static:
http://www.w3.org/Style/CSS/current-work#positioning
Whatever, I wouldn't really care yet :)
Answering body question:
The default is static so you'd be changing the property for every single item in the page. The best you can achieve is nothing. The worse is that you'll be probably creating weird side effects you won't even notice at first sight.
Also (this is pure speculation on my side), it can't be good for performance. I'm sure rendering engines are optimized for having a majority of static elements.
Related
From the W3C spec:
The containing block is established by the nearest ancestor box that
establishes an fixed positioning containing block, with the bounds of
the containing block determined identically to the absolute
positioning containing block.
Note: Properties that can cause a box to establish a fixed positioning
containing block include transform, will-change, contain…
I have seen quite a few issues detailing this confusing behavior, with many people calling it a "bug" despite it being explicitly defined in the specification for years.
That said, I personally cannot imagine a specific use case where you would ever want this to happen, and it seems to completely contradict the entire point of what "fixed" position is supposed to mean. For all the discussion I have found on stackoverflow and elsewhere, I have not seen a single comment explaining why this is a specified behavior.
I know there are workarounds and I'm happy to implement them. It would just give me tremendous peace of mind to know what the intended purpose of this rule is. Does anyone know?
As styling of a website/application gets more complex, and style sheets get bigger, I find that at some point inheritance starts adding to complexity.
You keep scrolling up and down through a long document to restyle a single element. You also need to keep in mind the consequences of any edits to all other tags/selectors that will inherit from it. Things break.
What if instead of that...
Each element's styles were fully contained within its ID/Class
Repetitive/common styles were applied using mixins and variables
(with Sass for example)
That way (my assumption):
Elements would be easier and more intuitive to style. Everything that makes an element look certain way is contained in one place. Elements could be customized as much as possible without breaking anything else - nothing inherits from anything else.
Global styling would still be possible, and easier too. You define global variables and mixins and use them as you see fit. That way, any element can "inherit" exactly what it needs, and nothing else.
Arguably, the resulting CSS would be bigger, but minification and ever increasing internet speed aside - this could make resulting CSS leaner too. Since each element is completely separate from all others (no cascade), you can easily just remove it. While with inheritance we're not always sure if removing something will break something else, so we keep piling up stuff.
Am I overlooking something here? Is there any downside to doing it like this?
Well Felipe is right that you will want to have your font applied to your html body, and do something similar for any other completely global styles. Otherwise your approach makes complete sense and greatly simplifies your design, which is one of anyones main goals.
I am a mostly skilled server-end developer, and am creating an ambitious website project - all by myself. I know c#, MVC, T-SQL, LINQ, and ASP.NET pretty well. Obviously, since I'm working by myself, I have knowledge in design too. I'm obviously good with html (who isn't?). And I absolutely love jQuery! The thing is, I'm decent in my understanding of css, but css is my least knowledgeable trait. I understand programming, I also am good in design, not just because I have a decent level of knowledge in css (and jQuery) - but also because I just know what looks good (I can draw and paint on real paper too).
The thing is, I know I can probably do this with jQuery code, but I was wondering if this could also be done with css alone. On my main design (Views/Shared/_Layout.cshtml) - I made the body to have a "min-width: (my value);" attribute, which, obviously isn't supported with older browsers, so I also included a transparent image of a default width of 1px that I set to stretch to my desired width also - it works in controlling the width of the page (to the minimum I desired). But - I have a site header div which resides at the top of the page. I have a part of that header div with elements positioned on the far right - which is nice when the browser is on a device that is large enough and the browser is in decent size, but once the browser is set to a size less than my desired minimum width, then the scroll bar shows up, and I can move it around as expected. But, the elements in that header div do not stay to the far right in conjunction with my minimum width - but stay on the right of the current window size instead. I have the main div holding the elements itself set to be in fixed position, I tried making those elements relative with no success. I tried a few ideas, the problem still persists.
So, as I said, I am well aware of concepts using jQuery that can do what I have previously described I desire in these regards, but, as I also said, I know a decent amount of css, but am the least close to an "expert" in css than anything else I know. I just have a strong suspicion what I desire here can be done with css and css alone (also, it would be nice to have it compatible with most browsers, or at the least most browsers made after the year 2008).
Can someone please give me some good information in these regards?
I just remembered asking this question.
I actually found a way to go about doing what I wrote I desired here through some experimentation that eventually got me to where I needed to be. What I did was instead of using relative positioning - which I thought was the proper way of doing this, I used absolute positioning inside the absolute positioned top header div. I didn't think this would be the solution at the time of asking the question, I assumed setting something as absolute positon - even inside something that is already absolute positioned - would put it in a new context of absolute positioning like any absolute positioned element inside the body tag. What I discovered was if I put an absolute positioned element inside another absolute positioned element - the context of the absolute positioning was based on the original absolute positioned element - so top (or left for that matter) 0px wasn't 0px from the context of the body (the very top of the page) - but - 0px from the element that the element is inside of. I think that's a pretty explanation of it, so I'll end explaining it here.
I'm sure there's plenty of people that know css much more than I do, and think this issue I had here is so basic, but, I did ask the question, and I might as well answer it based upon the solution I used. I could've posted an example on jsfiddle like asked for in a comment, but I thought my explanation was good enough, and since no one offered an answer based on my question alone, I decided to try to address the issue with experimentation, which I had success with.
I'm currently using 'float:left' to all of my tags when slicing. Whats wrong with it?
I think, the pros is I need not to do "clearing hacks" at all.
Sorry for my poor english.
I think by slicing he means starting a new line, it is true that adding float left to everything with the appropiate width will indeed induce a new line, what should happen if something needed to be of a negative margin, or float right, it would break your markup, you should check out your knowledge of tree structure in html, and avoid using floats where not necessary, instead use margins, relative positioning, or absolute, pages designed all in float are hard to appear correct in all major browsers as different broswers treat float irrespectively.
I feel like the problem is extremely apparent. I'm working on an issue with a client's site, which actually happens on several of my clients' sites but this one is the most apparent. IE7 Is refusing to obey z-index rules. I've played around with differing values, particularly on the divs #mapWrapper and #map. Take a look here: http://thepaysongroup.com/wp-content/plugins/hq_idx/searchlistings.php
I've done dozens of web searches and I can't find anything that resolves this issue. I also ready through Aleksandar Vacić's article on IE6/7 z-index discrepancies, but still nothing. Any assistance would be much appreciated, I'm tearing my hair out on this one.
In my experience, z-index in wonky in IE. Setting it to 0 is especially a problem, so make sure 0 isn't one of your z-index values.
Sometimes the simplest solution is to change the source-order of the html: whatever shows up later in the source will be on top. Is that a possibility in your case?
If I remember correctly, you can't have two elements with the same z-index or things get funky. I notice a lot of your paths have z-index of 1000. Some ideas to try:
Reset the z-indexes to be incremental within faux layers. That is, if you want all the boundary strokes to be on the same "layer", allocate the numbers between, say, 1001 and 2000 for that layer. The next layer above would use the numbers between 2001 and 3000, etc.
Let the document flow set the z-indexes within a few containers, and set the containers themselves to wide-apart z-indexes.
Note that historically with IE, elements like combo-box dropdowns and ActiveX controls, etc. get displayed on a layer above the actual page, and so always appear above any HTML, no matter how high you try to set the z-index. Not saying this is the problem, but perhaps using the map api triggers that problem. Read more here.
Okay, I figured it out. So the main navigation is in div #header with position: relative and no z-index defined. Once I placed a z-index on the header the menu popped right out in front of the map.
I guess the lesson here is look for every element with a defined position, be it absolute or relative, and how it is interacting with the elements in question.