Does Firefox have any support at all for the alignment-baseline property? When I inspect (using Firebug) SVG elements for which the alignment-baseline property has been explicitly set, Firebug does not list this property at all (IOW it treats is as noise). No matter what value I assign to this property, the appearance of the displayed text never changes, further suggesting that FF ignores this property altogether.
(One other sign that FF's support for this property may be busted is that the link given in the page cited above for the CSS documentation for this property is dead-as-a-doornail.)
Assuming that, as it appears, FF does not support the alignment-baseline property, what is the value of this property that would most closely replicate FF's default behavior?
EDIT: For example, view this jsFiddle with both Chrome and FF; each line of displayed text displayed a highlighted word that has been produced with code of the following form:
<tspan style="alignment-baseline:alphabetic">alphabetic</tspan>
Note that all the lines look the same in FF, but not so in Chrome.
There are a few possible candidate values for this property to replicate FF's default behavior (namely, auto, alphabetic, mathematic, and inherit); unfortunately, this experiment cannot decide the matter, and it's not clear to me which of the possible options would match FF's default behavior in the greatest fraction of cases.
It seems that alignment-baseline is ment to be used only for portions of <text>, that is for elements tspan, tref etc. For the main <text> element use the dominant-baseline attribute.
(This is what #Tanel Eero wrote above as a comment. I'm re-stating it here so the question can get an accepted answer).
The Mozilla Developer Network website states that the style can only be used on certain elements:
The following elements can use the alignment-baseline attribute
<tspan>
<tref>
<altglyph>
<textpath>
So that seems to be your main issue as I understand that you are trying to apply it to a SVG.
Related
So I was checking out the SVG display attribute and for my surprise, I've found two CSS2 deprecated values (at least for me), those are compact and marker. Does someone have got more info to the respect? If I'm not wrong, SVG and CSS share too many properties, but compact & marker values are deprecated since CSS3
this is text defined by the W3C
The latest version of the SVG specification simply hands off the definition of display and visibility to CSS.
See the CSS 2.1 specification for the definitions of display and visibility. [CSS2]
For display in SVG anything other than none is treated the same.
Elements that have any other display value than none are rendered as normal.
I am seeing a single dash in the Chrome developer tools as seen in the image below.
What does this refer to? If it had a digit associated with it I would think it meant negative.
Nothing.
That's not a valid value for this (or any) CSS property, it looks like whatever generated that style either failed to provide a value or it's inserting invalid values on purpose (whatever that might be)...
Inspect the element and on the Styles tab (on Chrome) if the property value is invalid it'll show with a yellow explanation mark.
Whomever wrote that code just didn't know what they were doing. They declare padding-right 3 times in one style attribute, and all of them are invalid values (including the one that just says -2 with no units. If we go to chrome dev tools and we apply that same property/value to an element, we get this:
when you hover on the yellow triangle, it tells you that the - is an "Invalid property value".
The problem is that I cannot use some inline SVG at all. I noticed about <object > and SVG problems in FF. But the fact is that many other ones are working.
I faced 2 icons from a designer that not working. Not even fill property. It's just invisible. Nothing helps.
I cannot provide more useful information. All icons work as is. Except for this 2. In chrome no problems.
Upd:
https://jsfiddle.net/u0t4tupu/4/
Here an example. These two svg use different clip-path. But in some reason first one makes second one invisible. Try this example in FF. Delete first icon or set them same clip-path - url(#svgicon-h). Then it works. But why?
You have two elements with
id="svgicon-a"
One in each SVG.
id attributes must be unique in a document. If there is more than one on a page the results are browser-dependent. That is why you get a different result on Chrome than you do in Firefox.
The fix is to change the id in one of the SVGs.
https://jsfiddle.net/u0t4tupu/5/
First of all, I did use Google and SOF Advanced search but I didn't find this question.
Now to my question:
I know that initial sets the shadow to default i.e none.
Then what is the difference between these two keywords WHEN APPLIED TO BOX-SHADOW PROPERTY.
For some properties, none doesn't work so that time it is understood but it doesn't make sense in box-shadow and other such properties.
And I did read w3schools initial keyword page completely and I made this thread after reading that so please don't stick me that. :)
Please help me clear my doubt. :)
There is no difference according to CSS specifications and drafts. However, there is a practical difference, because not all browsers support the initial keyword. Such browsers ignore a declaration with the value initial. (If no other style sheet sets the property for an element, then the valus of the property is still its initial value.)
According to the CSS Values and Units Module Level 3 CR, initial “represents the specified value that is designated as the property's initial value”. For the box-shadow property, this value is none.
This seems like a rendering engine quirk, as it had been tested and failed to reproduce on WebKit driven browsers (Chrome and Safari for Windows).
Description
When using a deep nested DOM structure, such as the GXT Grid, the default cursor seem to override any other style applied. How to override (or sidestep) this behavior?
Test Case
Steps To Reproduce
(Requires basic knowledge of your favored browser's developer tools)
Visit the GXT 2.2.x examples showcase.
Right-click a cell text value in the grid and click Inspect Element, or hit F12 to open the developer tools and than inspect that element manually. You should be inspecting an element notated as: div.x-grid3-cell-inner.x-grid3-col-name.
In the Styles view, look for a rule matching the following selector: .x-grid3-row, it should have a single declared property for cursor. Change its value from default to auto.
Expected Result
The cursor should be rendered according to the element's type, e.g. text cursor for text content elements.
Actual Result
On Gecko based browsers, the default cursor appears regardless of the element's type.
This is a known issue caused by ancestor elements with a declared tabindex attribute with a value equals or larger than 0, and is a reported bug in the Mozilla bug tracker.
It can be reproduced by running this simple test case on Gecko browsers (run on WebKit for a reference).
As a workaround, one can ensure all elements up the hierarchy are assigned with a tabindex value of -1, or remove those altogether, thus avoiding entering this block, turning cursor related CSS rules back to their normal behavior.