Consider leaving SVG mapped attributes enabled when page styles are turned off

RESOLVED FIXED in mozilla22

Status

()

--
minor
RESOLVED FIXED
8 years ago
4 years ago

People

(Reporter: dholbert, Assigned: bzbarsky)

Tracking

(Blocks: 1 bug)

Trunk
mozilla22
Points:
---
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

8 years ago
In current mozilla-central, when you disable page style ("View | Page Style | No Style"), SVG's mapped attributes are all disabled (reset to their default values).

This makes some amount of sense, spec-wise -- those attributes are all mapped into CSS rules per the SVG spec, so it's unsurprising that they're all disabled when style is disabled.

However, apparently IE9* and Opera 11** differ from us on this -- they leave SVG mapped attributes in effect when their "disable page styles" options are toggled.  From an author's perspective, their behavior is arguably more intuitive than ours, since authors don't necessarily know or care which SVG attributes are mapped into style rules.  They likely expect style-disabling to just turn off the "style" attribute and explicitly-included stylesheets.

So, I'm filing this bug about possibly changing to match Opera & IE on this -- leaving SVG mapped attributes in effect when page styles are turned off.

* see bug 606977 comment 12
** see bug 606977 comment 14
Do many people actually use that "No Style" option? Seems doubtful, but maybe I'm wrong.
Severity: normal → minor
It’s useful for printing, which was the reason I filed bug 606977 as logos on the page were turning out all black. It may be minor, but its more important for feature/behaviour parity imo.
you can use a link element with media="print" and define the colours you want to output for priting for that can't you? Then you wouldn't even have to change the styles you could just print and it would work.
(In reply to Daniel Holbert [:dholbert] from comment #0)
> This makes some amount of sense, spec-wise -- those attributes are all
> mapped into CSS rules per the SVG spec, so it's unsurprising that they're
> all disabled when style is disabled.

This is not that clear in the spec

In http://www.w3.org/TR/SVG11/styling.html#AlternativesForStyling you can read:
"The presentation attributes are style sheet language independent"

But in http://www.w3.org/TR/SVG11/styling.html#UsingPresentationAttributes you can read:
"For user agents that support CSS, the presentation attributes must be translated to corresponding CSS style rules according to rules described in Precedence of non-CSS presentational hints ([CSS2], section 6.4.4), with the additional clarification that the presentation attributes are conceptually inserted into a new author style sheet which is the first in the author style sheet collection. The presentation attributes thus will participate in the CSS2 cascade as if they were replaced by corresponding CSS style rules placed at the start of the author style sheet with a specificity of zero. In general, this means that the presentation attributes have lower priority than other CSS style rules specified in author style sheets or ‘style’ attributes."

So it seems that Firfox behavior is spec compliant on that point despite there is nothing explicit about "disabling" CSS.

However, it could also be considered that when a user turn of CSS then the browser become a browser agent that does not support CSS and in that point of view, you can assume that according to http://www.w3.org/TR/SVG11/styling.html#UsingPresentationAttributes
"User agents that do not support CSS must ignore any CSS style rules defined in CSS style sheets and ‘style’ attributes."

and therefor, according to http://www.w3.org/TR/SVG11/styling.html#AlternativesForStyling
"Conforming SVG Interpreters and Conforming SVG Viewers are required to support SVG's presentation attributes."

Which could be interpreted as "if style sheets are disabled, SVG presentation attributes should still be interpreted".

And it seems that it is the choice made by Microsoft and Opera.

I think there is a lack of specification here and this should be posted and discussed on the SVG WG mailing list.

> However, apparently IE9* and Opera 11** differ from us on this -- they leave
> SVG mapped attributes in effect when their "disable page styles" options are
> toggled.  From an author's perspective, their behavior is arguably more
> intuitive than ours, since authors don't necessarily know or care which SVG
> attributes are mapped into style rules.  They likely expect style-disabling
> to just turn off the "style" attribute and explicitly-included stylesheets.

I agree. As a Web author, it's exactly what I'm expected: for me attributes are not CSS related (even if it's possible to substitute them to a CSS property)

Even if the SVG spec is quite clear on the fact that those attributes are CSS dependent, FWIW, in that case, it's somewhat counter intuitive and should be clarified at the spec level.
Just been bitten by this again; after resolving to make certain my SVGs had the correct even-odd arrangement so at least a monochrome outline version would be presented, now I’ve bumped into masks not being usable at all when this is triggered.
Posted to www-svg to see if they have any feedback.
(Assignee)

Comment 6

6 years ago
Created attachment 726812 [details] [diff] [review]
Just fix it
Attachment #726812 - Flags: review?(jwatt)
Attachment #726812 - Flags: review?(dbaron)
(Assignee)

Updated

6 years ago
Assignee: nobody → bzbarsky
(Assignee)

Updated

6 years ago
Whiteboard: [need review]
Comment on attachment 726812 [details] [diff] [review]
Just fix it

Review of attachment 726812 [details] [diff] [review]:
-----------------------------------------------------------------

::: layout/style/nsStyleSet.cpp
@@ +316,3 @@
>                                 aType == eStyleAttrSheet)) {
> +    // Don't regather if this level is disabled.  Note that we gather
> +    // preshint sheets not matter what, but then skip them for some

*no matter
Attachment #726812 - Flags: review?(jwatt) → review+
Tested patch with URL, and another useful test case found in bug 779029 https://bugzilla.mozilla.org/show_bug.cgi?id=779029#c0 confirms the patch makes the behaviour afaics as spec.
One concern here is that if authors do care about the behavior here, this could cause them to convert CSS to attributes.
That's true, but for most of the SVG stuff CSS really doesn't make that much sense anyway.  In my opinion.  fill and stroke colors are about the only exceptions.... maybe.
Comment on attachment 726812 [details] [diff] [review]
Just fix it

> nsresult
> nsStyleSet::SetAuthorStyleDisabled(bool aStyleDisabled)
> {
>   if (aStyleDisabled == !mAuthorStyleDisabled) {
>     mAuthorStyleDisabled = aStyleDisabled;
>     BeginUpdate();
>     mDirty |= 1 << eDocSheet |
>-              1 << ePresHintSheet |
>+              1 << eScopedDocSheet |
>               1 << eStyleAttrSheet;
>     return EndUpdate();
>   }
>   return NS_OK;
> }

Maybe put the addition of eScopedDocSheet in a separate changeset, since it's really a separate change?

r=dbaron, I suppose (see previous comment)
Attachment #726812 - Flags: review?(dbaron) → review+
(In reply to Boris Zbarsky (:bz) from comment #10)
> That's true, but for most of the SVG stuff CSS really doesn't make that much
> sense anyway.  In my opinion.  fill and stroke colors are about the only
> exceptions.... maybe.

Dunno.  I found it pretty useful, e.g., in http://dbaron.org/senate-classes/class1-current.svg , to make things simpler.


Then again, I guess the other question is why people would turn off style in the first place.  It's hard to know what the feature should do without knowing why it's there.
Blocks: 1129095
You need to log in before you can comment on or make changes to this bug.