Confirmed users, Bureaucrats and Sysops emeriti
969
edits
SVG:Language:Regrets: Difference between revisions
no edit summary
No edit summary |
No edit summary |
||
| Line 34: | Line 34: | ||
IMNSHO, we should have had 'none' plus six other values (not eight): 'fill', 'stroke', 'both' and 'paintedFill', 'paintedStroke', 'paintedBoth'. The former three would have ignored opacity and visibility, the latter three would not. In fact, for reuse in CSS box model contexts such as HTML where you have 'background' and 'border' instead of 'fill' and 'stroke', the names would be 'perimeter', 'interior', 'both', and 'paintedPerimeter', 'paintedInterior', 'paintedBoth'. | IMNSHO, we should have had 'none' plus six other values (not eight): 'fill', 'stroke', 'both' and 'paintedFill', 'paintedStroke', 'paintedBoth'. The former three would have ignored opacity and visibility, the latter three would not. In fact, for reuse in CSS box model contexts such as HTML where you have 'background' and 'border' instead of 'fill' and 'stroke', the names would be 'perimeter', 'interior', 'both', and 'paintedPerimeter', 'paintedInterior', 'paintedBoth'. | ||
Hmm, note that in the CSS case, 'background-color' has an initial value of 'transparent', which results in a computed value of 'rgba(0,0,0,0)'. That probably has implications for CSS compatibility with the existing or proposed [initial] values. | |||
The current specification makes the value of the 'visibility' property special, but for some strange reason ignores the effects of opacity. As a result the 'visible' in value names such as 'visiblePainted' is nothing to do with whether something visible is actually painted, but rather to do with whether the 'visibility' property is set to 'visible' or not. The 'fill-opacity', 'stroke-opacity' or 'opacity', or the 'fill' or 'stroke' properties with rgba()/hsla() values that set opacity to zero, could all prevent any paint from being output, but as far as 'visiblePainted' et. al. are concerned, it's visible and painted if 'visibility' is set to 'visible'. Perhaps these values could be fixed to take account of opacity? | The current specification makes the value of the 'visibility' property special, but for some strange reason ignores the effects of opacity. As a result the 'visible' in value names such as 'visiblePainted' is nothing to do with whether something visible is actually painted, but rather to do with whether the 'visibility' property is set to 'visible' or not. The 'fill-opacity', 'stroke-opacity' or 'opacity', or the 'fill' or 'stroke' properties with rgba()/hsla() values that set opacity to zero, could all prevent any paint from being output, but as far as 'visiblePainted' et. al. are concerned, it's visible and painted if 'visibility' is set to 'visible'. Perhaps these values could be fixed to take account of opacity? | ||