padding:initial vs. padding:0 - html

Does padding:initial have any advantage over padding:0? Example:
<style>
textarea {
padding: 0;
}
</style>
<textarea>Hello, world!</textarea>

They mean the same thing, as the initial value of padding is, in fact, zero on all sides. You can find this in the propdefs for padding and its longhands in this section of the spec.
In this case, given the nature of the padding property, and the fact that its initial value is basically common knowledge at this point, there isn't much of an advantage of setting padding: initial over padding: 0.
In fact, there's one disadvantage, and that is its as yet incomplete browser support owing to the fact that it's a relatively new keyword. Namely, if padding wasn't already zero on this element, browsers that don't support the keyword would ignore the declaration entirely, resulting in the property not being reset to zero.
The initial keyword is most useful when used with the new properties defined in the CSS3 Cascading module (none of which are implemented yet AFAIK, and where the keyword itself is defined). It can also be used when you simply want to reset a property to its initial value without caring what that value actually is, which is particularly useful for properties that are either inherited by default, such as color (although the initial value in that case would be currentColor), or in cases where the "initial" value can otherwise vary depending on the layout and thus cannot be determined as a fixed value. Such cases, however, are admittedly quite rare.
Lastly, note that "initial value" and "browser default value" are not the same; the initial value is defined by spec, which is separate from what value the browser assigns to certain properties on certain elements as part of its default stylesheet. There is no reliable way to reset a property to its browser default for the given element without using prior knowledge or even JavaScript to determine this default value. See this answer for an illustration.

Actualy both are same,But Initial gives the developer more freedom.(#simon's comment)It cannot be always zero,it can be any initial value.
So there isn't much advantage of using padding: initial over
padding: 0
The initial CSS keyword applies the initial value of a property to an element. It is allowed on every CSS property and causes the
element for which it is specified to use the initial value of the
property.
Another Example
<p style="color:red">
this text is red
<em style="color:initial">
this text is in the initial color (e.g. black)
</em>
this is red again
</p>
read through https://developer.mozilla.org/en-US/docs/Web/CSS/initial

Related

why does setting h1 all: intial makes it 19px

I want to make a part of my website display html in its defualt style essentially ignoring all other css files only for certain elements.
So I try all: initial !important; It gives me the output I want but when using h1 tag the output text has font-size 19px which should be 32px instead, is there something I am doing wrong or is this a browser bug?
edit: when using revert I get weard effect see:https://imgur.com/a/pEmJFpw
for more explanation see my comment below this post
You need to consider the use of revert
The revert CSS keyword reverts the cascaded value of the property from its current value to the value the property would have had if no changes had been made by the current style origin to the current element. Thus, it resets the property to its inherited value if it inherits from its parent or to the default value established by the user agent's stylesheet ref
initial won't be good because it does something different
The initial CSS keyword applies the initial (or default) value of a property to an element. It can be applied to any CSS property. This includes the CSS shorthand all, with which initial can be used to restore all CSS properties to their initial state.
Note the of a property. So initial won't consider the default CSS of the browser.
Related: What's the difference between `all: unset` and `all: revert'

Why do the MDN docs state that the initial display value for all elements is inline?

This is clearly not the case as each element can have it's own default.
See here:
https://developer.mozilla.org/en-US/docs/Web/CSS/display
Initial value: inline
Applies to: all elements
And of course contradicting documentation which seems more correct in this case.
https://www.w3schools.com/css/css_display_visibility.asp
Is there something I'm missing here?
It seems to clearly state that "all elements" have "initial value" set to inline.
First of all w3schools isn't the official Documentation, W3C is!
TL:DR: You are confusing things -- The initial value of the property which is inline and to which elements the property applies (no matter the value it has)
They are not related.
Here is the official Documentation about it
Which match MDN Docs.
And yes the initial value of display is inline the line below (in your question) says it can apply display property to all elements, which is true and not starting "all elements" with inline, because if you read the MDN Docs you see this:
The display CSS property specifies the type of rendering box used for
an element. In HTML, default display property values are taken from
behaviors described in the HTML specifications or from the
browser/user default stylesheet. The default value in XML is inline,
including SVG elements.
(Emphasizes is mine)
And what that line means is any browser/user-agent are free to set the initial value of the element as they think it is better.
N.B. Remember that by initial value means using initial value itself, so whenever you set display:initial it will became display:inline as per the Documentation above states.
Initial value: inline
...states that official recommendation for user agents is to interpret display:initial as display:inline, not as the default value for the type of element (i.e. block for <div>, inline-block for <span>, etc...).
So, in practice, setting display:initial; on a <div> will apply display:inline; to it in user agents respecting the standard recommendation, instead of display:block; as most developers would be tempted to assume. Setting display:initial; on any element should be interpreted as display:inline. That is what it means.
Ultimately, this is useful as it reduces ambiguity around a complex attribute, such as display.
As for why does MDN provide this information, generally speaking, there are very few (if any) contradictions between MDN and W3C/official sources, which makes it a valuable and reliable resource. Its main quality is it presents the information in a more accessible format (than the official docs) for people without a solid background on web technologies/concepts.
Personally, besides reading the articles/examples themselves, I find myself using it a lot as the fastest way to get the full list of official resources about any web concept, as you'll always find the links at the end of the MDN article on the subject (where applicable).
Those two things aren't related.
The initial value of a property refers to the CSS-defined default value for that property. Every single CSS property has an initial value, regardless of element type, because CSS properties aren't tied to elements of any document language in any way. This initial value is intended as a default value for unrecognized elements, to guarantee that every element has a value for every property for the purposes of the cascade and therefore ensure that a browser knows how to render that unrecognized element as it encounters it.
The so-called "default value" of a property is just an arbitrary value set by a browser in its UA default stylesheet. The HTML5 spec contains a reference document on what default values should apply to what HTML elements, which browsers follow mostly, but this is completely unrelated to CSS's concept of an initial value (nor does it contradict its definition of initial value, because it defines default styles separately as "user-agent-level styles").
"Applies to", on the other hand, is unrelated to the initial value. Even if a property only applies to certain types of elements, those elements will always have every single CSS property, including properties that don't apply to them. What "Applies to" actually means is "Has effect on". If a property doesn't apply to an element, it simply means that it has no effect.
For example, you may find that the flex property only applies to flex items. However, every single element has a flex property, regardless of whether it's actually a flex item, and they pretty much all have its initial value simply because I'm not aware of any UA styles altering its value from the initial value for any element. You could still set an arbitrary value on an element that isn't a flex item, and it simply would have no effect — but you could, for example, force flex items that are children of this element to inherit this value with flex: inherit (you wouldn't actually do this, I'm just stating an example).
In fact, a real-world example of this exists in the ul and ol elements — many authors (including myself) set list styles on those elements, when really the list markers you see belong to their li children that are inheriting their list styles, since list styles only apply to list-items and ul and ol are not themselves list items.
And as mentioned, W3Schools isn't official documentation. To save you any more confusion, assume W3Schools does not exist. Continue using MDN if it is easier to understand, but always cross-reference with the official specs located at w3.org and whatwg.org (which MDN usually does a good job linking to, it pretty much never links to W3Schools).
Each user agent(browser) applies a default style sheet for an HTML page. You can see in the default HTML4 style sheet:
dir, hr, menu, pre { display: block; unicode-bidi: embed }
li { display: list-item }
head { display: none }
...
The default display property is changed depending on the element.
That would be true for a native xhtml browser. HTML browser is something else completely, it doesn't have to wait for separate instructions. In HTML all known elements have their display rendering predefined by default.
(Which of course can be overridden).
There were browsers which didn't support styles at all. HTML tags are semantic. All xhtml is generic and of course to it all tags are equally [unknown] and indiscriminately inline by default.

Is there anything in the CSS spec that allows a percentage property to be relative to a specific element/property?

I want to be able to define what each property that allows a percentage is relative to.
According to the current W3 CSS Spec:
Percentage values are always relative to another value, for example a length. Each property that allows percentages also defines the value to which the percentage refers. The value may be that of another property for the same element, a property for an ancestor element, or a value of the formatting context (e.g., the width of a containing block). When a percentage value is set for a property of the root element and the percentage is defined as referring to the inherited value of some property, the resultant value is the percentage times the initial value of that property.
I want to define what value an element's percentage should be based. I want to reference:
The ancestor element the property's percentage is based on.
The property of the specified element the property's percentage is based on.
I have many times had problems with the percentage value of the properties line-height (which is based on font-size) and padding & margin (which is based on width even for padding-top & padding-bottom/margin-top & margin-bottom). I understand that currently there is no way to do what I'm talking about, but I've searched through the CSS spec for anything related to this and I have come up empty handed.
Is there anything in the current spec (that I was unable to find) that allows what I'm trying to do? If there's nothing in the spec, are there:
Any discussions/ideas about this concept?
Is what I'm thinking of not possible for some reason?
It seems to me that it should be possible as a property the same way transition is.
syntax: <single-relative-property> || [none | this | parent] || <single-relation-property>
Example
.text{line-height:100%;relative:line-height height;} This element's line-height is 100% of it's own height.
.text{padding:5% 0;relative:padding-top parent height, padding-bottom parent height;} This element's padding-top & padding-bottom are both 5% of it's parent's height.
Please note, I know that there are work arounds for some of these things. I also know all of this can be done with javascript. I'm more curious if it was ever talked about/mentioned anywhere, and if not why? Because this seems like it could be something helpful.
I also understand that in a flexbox layout the padding & margin properties are based on their percentages respectfully which is awesome. But that is not what I'm looking for.
When the spec says...
Each property that allows percentages also defines the value to which the percentage refers.
... this definition is given by the spec, and then a conforming user agent implements the calculation according to the spec. The spec does not make any reference to user-defined percentage calculations. If I were to hazard a guess, it's probably because it's altering how a built-in CSS unit fundamentally works could potentially open developers up to a plethora of complications.
The calc() function, introduced here in the same spec that you link to, by itself does not allow you to specify a CSS property, either of the same element or some other element, which means for example you can't do something like this:
.text {
height: 100px;
line-height: calc(100% * height);
}
However, there's a newly-published draft called CSS Custom Properties for Cascading Variables, which allows authors to specify custom property values and use them in arbitrary rulesets in a stylesheet. And while the module itself doesn't discuss a way for users to define how percentages should be calculated, it does discuss using cascading variables with calc().
This is very promising: since you're already able to perform multiplication and division with calc(), you can fully emulate percentage calculations by multiplying by a decimal number instead of a percentage (or just use the cascaded value as is for 100%). You can even force properties that don't normally accept percentages, such as border-width, to have their values calculated based on some other property using this method.
Here's an example, with an interactive proof-of-concept that works in Firefox 31 and later, where the current draft is implemented as of this writing:
.text {
--h: 50px;
height: var(--h);
/* 100% of height, given by --h
Line height percentages are normally based on font size */
line-height: var(--h);
/* 20% of height, given by --h
Border properties do not normally accept percentages */
border-width: calc(0.2 * var(--h));
border-style: solid;
}
The only caveat is that, because var() only works with custom properties, you need to
declare the value in its own custom property, and then
any property that depends on this value must access the custom property through var().
But the fact that it works is in itself very, very promising and we can only hope that this new module will continue to be developed and be more widely implemented.

How to solve the conflict between reset.css/normalize.css and the 'initial' CSS prop value?

There is a new value in CSS3 called 'initial', it will reset the prop's value to the browser's default.
The spec here: https://developer.mozilla.org/en-US/docs/Web/CSS/initial
But in most times, a website/webpage often have a reset.css or normalize.css file apply to the site/page.
So in most cases, I want the prop which set to 'initial' to be the reset.css or normalize.css's value but not the browser's default, how to solve the conflict between those two?
There is a new value in CSS3 called 'initial', it will reset the prop's value to the browser's default.
That's where most people are mistaken (even I got it wrong once). The initial value is not the same thing as the browser's default value.
A browser default is set by the browser in its default stylesheet.
The initial value of a property is the default that is stated in the spec. The initial value is usually the same regardless of what element you apply the property to; it's the browser that decides whether it should apply a different value to different elements by default.
For example, the initial value of display is inline — many HTML elements default to display: block, but setting display: initial will turn them into inline elements, not block elements.
Even the document you link to itself links to another document defining the term "initial value":
The initial value given in the summary of the definition of each CSS property has different meaning for inherited and non-inherited properties.
With all that said, there is currently no way using CSS to reset a property to either a browser's default or an arbitrary level in the cascade (e.g. normalize.css or a reset stylesheet).

is it OK to use inherit value for ALL non-inherited css properties?

https://developer.mozilla.org/en/CSS/inherit:
For non-inherited properties, inherit specifies a behavior that
typically makes relatively little sense.
I'm wondering what exactly is the page trying to say. So is it telling us that when we do inherit for a property which is non-inherited, the behavior is not standardized (may and may not work) ?
Because I've tried inherit value for border in FF, Chrome, IE, Safari, and Opera and they all work?
is it OK to use inherit value for ALL non-inherited css properties? are they part of the w3c standard?
So is it telling us that when we do inherit for a property which is non-inherited, the behavior is not standardized (may and may not work) ?
It works as expected in anything but IE < 8, but why would you want to make every property inherit? If you specify a border for a parent element E, then specify border: inherit for E *, then everything descending from E is going to get the same border.
is it OK to use inherit value for ALL non-inherited css properties?
You can do so for a specific property if you really want an element to inherit that style from its parent, but it doesn't make sense for most designs in general to do it for every single property, unless your design is specifically about outlining every single rectangle with a thick red border. As an example, take a look at this catastrophic mess of a page.
are they part of the w3c standard?
If the spec lists inherit as a valid value for that property, whether it's "non-inherited" or not (which means it isn't inherited by default), then it's technically supposed to work.