Closed Bug 267713 Opened 20 years ago Closed 20 years ago

use of a class disables change of css style via script.

Categories

(Core :: SVG, defect)

Product:
Core
Component:
SVG
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: jay, Unassigned)

References

(
URL
)

Details

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a5) Gecko/20041102
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a5) Gecko/20041102

onmouseover the graphic should provide a highlight and this works in asv3


Reproducible: Always
Steps to Reproduce:
1.open file
2.mousover graphic
3.

Actual Results:  
nothing

Expected Results:  
highlight 'border' should be seen (stroke-width attribute changed)

compare with http://peepo.co.uk/temp/css-script.svg an identical file, but
without class, which works in mozSVG.
*** Bug 267720 has been marked as a duplicate of this bug. ***
*** Bug 267721 has been marked as a duplicate of this bug. ***
*** Bug 267722 has been marked as a duplicate of this bug. ***
*** Bug 267714 has been marked as a duplicate of this bug. ***
*** Bug 267715 has been marked as a duplicate of this bug. ***
The "stroke-width" attribute is a presentational hint, and thus has lower
precedence than other style rules (eg the one that matches on class).

So the observed behavior looks correct to me (and Adobe's looks wrong).
Boris,

how are you proposing that authors or more importantly users use script to
change  style attributes?

it isn't always appropriate to user classes within style sheets, consider a
slider that changes an attribute such as style width for the user.
I've not included this, to keep the example simple.

Style sheets and classes are useful for gross changes, then one may need script
for fine tuning.
jonathan, the point is that the "style" attribute and what you're calling "style
attributes" have different precedence in the CSS cascade.  Please see
http://www.w3.org/TR/CSS21/cascade.html#q13 for the details.

So the key is that you are NOT using CSS.  Thus the attributes that you're using
are overridden by CSS if it's present.

So if you want to override a CSS class, you would need to use an appropriate
"style" attribute instead of using the presentational hints.
In fact, see http://www.w3.org/TR/SVG11/styling.html#UsingPresentationAttributes
which clearly says:  

  For user agents that support CSS, the presentation attributes must be
  translated to corresponding CSS style rules according to rules described in
  section 6.4.4 of the CSS2 specification, Precedence of non-CSS presentational
  hints, 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.

Whatever "asv3" is, if it supports CSS it's in clear and flagrant violation of
this specification.  I'm  surprised the SVG 1.1 test suite doesn't have tests
for this sort of thing...

Based on the clear statement from the spec above, I'm marking this invalid.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
Boris,

marking as invalid isn't good enough.

you need to provide a - working - example of how you imagine this does work.

as you say there should be a test suite example.

regards
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Jonathan, it isn't Boris' job to propose or provide a way for you to change
"style attributes" (presentational attributes). As Boris says, we behave exactly
as the W3C specs say we should. The fact is that CSS properties specified in the
'style' attribute simply override SVG presentational attributes. When you change
the value of those presentational attribute in your script, that value is
changed, but it is still overriden by the CSS property. Remove the CSS property
and you will see that it worked. What you need to do is use your script to
change the *CSS property*.

> marking as invalid isn't good enough.

Pardon? Boris is a highly experienced and valuable contributor to Mozilla - he
is a peer for DOM, the HTML style system and the layout engine amoungst other
things. Just take a look at his bug list.

https://bugzilla.mozilla.org/buglist.cgi?emailassigned_to1=1&emailtype1=exact&email1=bzbarsky%40mit.edu

I for one very much value any input he makes to the SVG project - please treat
him with the respect he's due. If he marks a bug INVALID he's very unlikely to
have made a mistake. Please *especially* don't change a bug's resolution and
then come into #svg and admit you didn't understand the argument for closing it
in the first place. Ask for clarification in the bug - we still get the bugmail
even when bugs have been closed.

> you need to provide a - working - example of how you imagine this does work.

No he doesn't. This isn't "script school", it's bugzilla - for bugs in the
Mozilla code. Go and read the relevant parts of the SVG and CSS specs to
understand how to change CSS properties from your scripts, or ask in
svg-developers or something. Developers like Boris are too scares a resource to
use up their time tutoring individuals when there are so many other people who
could answer scripting related questions for you. If you can't get an answer
from elsewhere ask in #svg and I'll show you.

Marking INVALID
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → INVALID
I'd appreciate that script example...

 I do like you, value Boris, however I also consider that SVG would benefit from
having someone pre-literate on the team.
 and in my consideration provided they were respected by the team, this would be
far more valuable than any skilled contributor.
 Just now that is, whilst there are plenty of skilled programmers, but very  few
unskilled users contributing bugs

 you cant make accessible viewers or authoring tools without contributions from
users, 

a practical solution maybe to to use:
setAttributeNS(null,'style','...')

I'd like to see a snippet, as I'm not so sure....
For a practical solution, it seems to me that
http://w3.org/TR/SVG11/svgdom.html#CSSDOMFeaturesWithCSSSupport second paragraph
says that using

  obj.style.setProperty("stroke-width", "50", "");

instead of

  obj.setAttribute("stroke-width", "50");

should work fine (and does, in Mozilla).
boris,

that really is very annoying, I discovered that over the weekend, for some other
issue, and have implemented it in fact....
http://www.peepo.co.uk/style/contrast.svg  my take on contrast controls.

anyway I raised the ante on contrast (of which this was part), as it may be that
whilst OS can offer style controls SVG should have special ability, that is
until it is the desktop :-)

of course without a great test suite, it's difficult to be sure..... 

please understand I have really serious memory problems.

thanks again and regards

any value other than "null" or ""? is there a difference between these two?
> any value other than "null" or ""? is there a difference between these two?

I'm not sure I understand the question.
well asv doesn't require the additional ,"" or ,"null" so just wondering what
this might be a placeholder for.... else why require it?
> well asv doesn't require the additional ,"" or ,"null" so just wondering what
> this might be a placeholder for.... else why require it?

You can pass "important" instead of "" to set the property's value as !important
(see CSS specification).

Jonathan, the interface you are looking for is:

http://www.w3.org/TR/DOM-Level-2-Style/css.html#CSS-CSSStyleDeclaration

The third parameter is a string. If you don't want to give the property an
importance you should pass the empty string "" to that parameter, not the
JavaScript value 'null'. In practice 'null' will be converted to the empty
string where ever a string is required, so you won't have noticed that 'null'
isn't correct.

See me on IRC for discussion about the other things you have talked about here.
You need to log in before you can comment on or make changes to this bug.