Errata

"we emphasize that using style attributes or..."

While I understand the argument that presentational attributes mix the concerns of structure and presentation in the xml/markup, I don't really see the improvement when using specifically inline style attributes. Inline style attributes are, in fact, an attribute of the xml, so aren't they also mixing such concerns? From a practical standpoint, by using inline style attributes I've coupled the style to that element.

To my mind, a style would need to at least be defined in the <defs> and preferably externally/outside of the svg to be fully decoupled.

Note from the Author or Editor:
Those are all good points, Rob. Style attributes do not have the re-usability benefits of stylesheets that are described in the rest of the paragraph, and the text could have been clearer about that distinction.

A better wording would be:

Again, we emphasize that using style attributes or stylesheets should always be your
first choice. Stylesheets, in particular, let you apply...

("in particular" added)

Style attributes nonetheless have other benefits relative to presentation attributes: they clearly indicate which aspects of the element are styles that could be inherited by child elements; and they ensure that the styles you're intentionally applying to a particular element are actually applied, regardless of other CSS. Using presentation attributes can cause unexpected results when a CSS rule takes precedence, as the snippet earlier on p61 emphasizes.

That said, I often use presentation attributes myself in simple examples, because they are easy to write. (I think David is a bit more of a stickler for the separation of presentation versus structure.) And occasionally I use them because I want to be able to over-ride the styles with CSS if need be, although that can make for confusing code if you're not careful.

Page 59 section External Stylesheets advises:

* { ... }

Since this will cause engine to have to look at every single element on page (not just SVG) and is now considered a taboo practice, I'd suggest at minimum to scope the universal selector with something like:

svg * {...}

Note from the Author or Editor:
That particular example (Example 5-3 in printed versions) was really more of a demonstration of what is possible than a recommend practice. That said:

I haven't seen any reliable data on * selectors having significant performance impacts on modern browsers (anything that would support SVG). They are often used to reset browser defaults. If anything, `svg *` would be more of a performance hit because it (a) selects all elements, then (b) checks to see if they have an SVG ancestor. This may be counter-intuitive, but it is how most browsers work!

Using `svg *` could also complicate things because it changes the specificity of the selector. The `*` selector alone has zero specificity, and is over-ridden by any other CSS rule applied to the same element. However `svg *` has equal specificity to `circle` or `path`, so you would have to be careful about the order in which rules are encountered. If the rule was at the top of the stylesheet, and you only had one stylesheet, no problem. Otherwise, things could get confusing.

For the general rule of setting default stroke and fill values, I would actually recommend using `svg { /* default styles */ }` to set defaults to be inherited by every element. This allows you to change the defaults for a section of the graphic by setting new styles on a group element, instead of having to target each element individually.

However, the `*` selector has one very important use case: over-riding presentation attributes created by a WYSIWYG program like Inkscape or Illustrator. For example, `* { fill: inherit; stroke: inherit; }` will force the program to ignore presentation attributes for fill and stroke and use the inherited value unless other CSS rules set different values.