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

Status: RESOLVED FIXED

(Core :: SVG, defect)

Description

[Daniel Holbert [:dholbert]]

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

Comment 1

[Jonathan Watt [:jwatt]]

Do many people actually use that "No Style" option? Seems doubtful, but maybe I'm wrong.

Comment 2

[John Drinkwater (:beta)]

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.

Comment 3

[Robert Longson [:longsonr]]

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.

Comment 4

[Jeremie Patonnier :Jeremie]

(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.

Comment 5

[John Drinkwater (:beta)]

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.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Attachment: Just fix it

Comment 7

[Jonathan Watt [:jwatt]]

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

Comment 8

[John Drinkwater (:beta)]

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.

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

One concern here is that if authors do care about the behavior here, this could cause them to convert CSS to attributes.

Comment 10

[Boris Zbarsky [:bzbarsky]]

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 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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)

Comment 12

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(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.

Comment 13

[Boris Zbarsky [:bzbarsky]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/423f679f1d44
https://hg.mozilla.org/integration/mozilla-inbound/rev/71cf55aee147

Comment 14

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/423f679f1d44
https://hg.mozilla.org/mozilla-central/rev/71cf55aee147