Added the SVG reference and some notes for CSS restrictions

[iherman]

This is a PR for #1614 (and for the corresponding WG resolution).

• Added a reference to the SVG direction attribute (to be used instead of the CSS direction property). I had to rephrase the bullet item texts to make it a bit more readable
• Added a note for the background of these restrictions
• Added a note in the RS document that RS-s can "do what they damn well please" :-)

One discrepancy I encountered is that there seems to be no equivalent to a bidi element in SVG2. Ie, the restriction on the unicode-bidi CSS property does not apply to SVG2.

(I may have misunderstood something. Maybe @fantasai can help out on this.)

• For Preview on the EPUB 3.3 Reading Systems:
  • Preview
  • Diff

---

Preview | Diff

[mattgarrish]

One discrepancy I encountered is that there seems to be no equivalent to a bidi element in SVG2. Ie, the restriction on the unicode-bidi CSS property does not apply to SVG2.

The SVG unicode-bidi attribute maps to the CSS property, so why would it be appropriate to use CSS instead of the attribute?

That HTML also has a bdo element doesn't appear of consequence.

[mattgarrish]

I think we should state more generally that authoring restrictions are not applicable to reading systems, as the CSS properties are only one case of restrictions we impose on HTML, MathML, SVG, etc.

I was thinking after the call we should probably have a statement more like the following somewhere:

The definition of EPUB Content Documents includes various authoring restrictions to optimize the cross-compatibility of content (e.g., prohibiting CSS for setting language and direction). Unless stated otherwise in this specification, Reading Systems MAY support these restricted features.

(Bolding's sort of a polite way of screaming to do what you please.)

Maybe this could float at the start of the content documents section, or maybe it would be better to incorporate into a section on authoring restrictions?

[iherman]

One discrepancy I encountered is that there seems to be no equivalent to a bidi element in SVG2. Ie, the restriction on the unicode-bidi CSS property does not apply to SVG2.

The SVG unicode-bidi attribute maps to the CSS property, so why would it be appropriate to use CSS instead of the attribute?

There is something strange happening that I do not understand. I see no definition for the unicode-bidi property in SVG. It is used in an example and in the text in the section on direction but it all refers to the CSS spec only.

Is our requirement for the SVG case something like:

It MUST NOT use the unicode-bidi property [CSS-Writing-Modes-3] for [SVG] Content Documents. Use the [SVG] unicode-bidi and direction attributes to control bidirectionality.

Knowing that I cannot put a normative reference to an SVG reference to the unicode-bidi attribute but only to the CSS property definition? This is what bothered me...

I may miss something fundamental...

[iherman]

I think we should state more generally that authoring restrictions are not applicable to reading systems, as the CSS properties are only one case of restrictions we impose on HTML, MathML, SVG, etc.

I was thinking after the call we should probably have a statement more like the following somewhere:

The definition of EPUB Content Documents includes various authoring restrictions to optimize the cross-compatibility of content (e.g., prohibiting CSS for setting language and direction). Unless stated otherwise in this specification, Reading Systems MAY support these restricted features.

(Bolding's sort of a polite way of screaming to do what you please.)

Maybe this could float at the start of the content documents section, or maybe it would be better to incorporate into a section on authoring restrictions?

I actually like that, is it more future proof. It may be put into §4 before §4.1.

[iherman]

@mattgarrish, I have adopted your proposed change in dd58c50. However, I have not used the boldface; I do not think we use that type of typesetting trick elsewhere in the document, so it looked a bit out of place…

[mattgarrish]

I see no definition for the unicode-bidi property in SVG. It is used in an example and in the text in the section on direction but it all refers to the CSS spec only.

Right, the formal process of using css properties as attributes is defined under "presentation attributes".

For all the listed CSS properties there are equivalent svg attributes. The attribute are exact mappings to the css properties, which is why I don't believe we need to worry about bdo. That's for html which doesn't have this equivalency.

That's why they just talk about the "property" but then use it as an attribute. You could always link to the presentation attribute section, I suppose, as someone can find their way from there to the definition.

[mattgarrish]

I have not used the boldface; I do not think we use that type of typesetting trick elsewhere in the document

Oh, come on, take a walk on the wild side... :)

(Never say never... although I thought we had more.)

[iherman]

On the SVG bi-di stuff: here is what I have just committed for that item:

It MUST NOT use the unicode-bidi property [[!CSS-Writing-Modes-3]] for [[!SVG]] Content Documents. Use the [[!SVG]] presentation attribute alternative for unicode-bidi and the direction attribute to control bidirectionality.

How does that sound?

[iherman]

Oh, come on, take a walk on the wild side... :)

O.k., you win :-)

[iherman]

@mattgarrish I have finalized the stuff (essentially rolling back my last commit and modifying a little bit the note you provided).

[iherman]

@dauwhe @wareid could you look at this? It would be time to merge (also trying to avoid complex merge conflicts...)