SVG FXL restrictions on height and width may be too restrictive

[rdeltour]

Looking at the rules on how the Initial Containing Block dimensions are expressed in SVG

1. regarding their combination with viewBox, the spec says:

The spec says:

It is RECOMMENDED to use only the viewBox attribute to ensure proper rescaling of the SVG Content Document, as needed.

As far as I understand, percentage values do not negatively affect scalability, so should be fine in combination with viewBox.

This could be reworded to something along these lines:

It is RECOMMENDED to use the viewBox attribute to ensure proper rescaling of the SVG Content Document, as needed.
If height and width attribute are present, they values SHOULD NOT be set to absolute length when a viewBox attribute is present.

2. regarding the height and width pixel value

The spec says:

If only the x, y, height and width attributes are present, they SHOULD be defined in pixel values (establishing the ICB)

Given that all absolute length units are compatible (they can all be converted to the canonical px unit), requiring a pixel value looks restrictive. The term "pixel value" itself might be a bit vague (does it mean "in pixel units" or "in units compatible with the pixel unit"?).

This could be open to any absolute length:

If only the x, y, height and width attributes are present, their value SHOULD be expressed in user units or in absolute length units. (establishing the ICB).

3. regarding the impact of x and y on the ICB

The spec says:

If only the x, y, height and width attributes are present, they SHOULD be defined in pixel values (establishing the ICB)

I'm not sure the value of x and y is relevant there? The intrinsic sizing of SVG content is only impacted with width, height, and viewBox.

Suggested rewording:

If height and width attributes are present and there is viewBox attribute is not present, they SHOULD be defined in…

For reference, this section was discussed in #860, #800, #463.
See also EPUBCheck issue w3c/epubcheck#902 and PR w3c/epubcheck#973

[GeorgeKerscher]

Hello, SVG is very important to people with low vision. The SVG should be able to be enlarged by the user. I hope our incorporation of SVG in the spec supports this important feature. Best George From: Romain Deltour <notifications@github.com> Sent: Friday, February 22, 2019 8:52 AM To: w3c/publ-epub-revision <publ-epub-revision@noreply.github.com> Cc: Subscribed <subscribed@noreply.github.com> Subject: [w3c/publ-epub-revision] SVG FXL restrictions on `height` and `width` may be too restrictive (#1236) Looking at the rules on how the Initial Containing Block dimensions are expressed in SVG <https://w3c.github.io/publ-epub-revision/epub32/spec/epub-contentdocs.html#sec-fxl-icb-svg> 1. regarding their combination with viewBox, the spec says: The spec says: It is RECOMMENDED to use only the viewBox attribute to ensure proper rescaling of the SVG Content Document, as needed. As far as I understand, percentage values do not negatively affect scalability, so should be fine in combination with viewBox. This could be reworded to something along these lines: It is RECOMMENDED to use the viewBox attribute to ensure proper rescaling of the SVG Content Document, as needed. If height and width attribute are present, they values SHOULD NOT be set to absolute length when a viewBox attribute is present. 2. regarding the height and width pixel value The spec says: If only the x, y, height and width attributes are present, they SHOULD be defined in pixel values (establishing the ICB) Given that all <https://www.w3.org/TR/css3-values/#absolute-lengths> absolute length units are compatible (they can all be converted to the canonical px unit), requiring a pixel value looks restrictive. The term "pixel value" itself might be a bit vague (does it mean "in pixel units" or "in units compatible with the pixel unit"?). This could be open to any absolute length: If only the x, y, height and width attributes are present, their value SHOULD be expressed in user units or in absolute length units. (establishing the ICB). 3. regarding the impact of x and y on the ICB The spec says: If only the x, y, height and width attributes are present, they SHOULD be defined in pixel values (establishing the ICB) I'm not sure the value of x and y is relevant there? The intrinsic sizing <https://www.w3.org/TR/SVG/coords.html#SizingSVGInCSS> of SVG content is only impacted with width, height, and viewBox. Suggested rewording: If height and width attributes are present and there is viewBox attribute is not present, they SHOULD be defined in… For reference, this section was discussed in #860 <#860> , #800 <#800> , #463 <#463> . See also EPUBCheck issue w3c/epubcheck#902 <w3c/epubcheck#902> and PR w3c/epubcheck#973 <w3c/epubcheck#973> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1236> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AG3HSB4Iu2rghzqBwnV1lGV9AcTyHzBwks5vQBIGgaJpZM4bJ3wv> . <https://github.com/notifications/beacon/AG3HSBloWGDTHNxynpt27Wj_ntaT-zvyks5vQBIGgaJpZM4bJ3wv.gif>

[bduga]

Taking this in parts:

1. Allow percentage values for height and width in the svg element in svg content documents. What would it mean? So given this:
   <svg ... viewbox="0 0 100 50" width="50%" height="100%"> ... </svg>
   when I display this on a device that is 800 pixels wide by 1200 pixels tall, how big should the svg be? 800x600? 1200x400? 400x600? I am not sure what the answer would be, and in any case the percentages are likely undefined. For instance, CSS says for width:

The percentage is calculated with respect to the width of the generated box's containing block.

But we are calculating the ICB here, so by definition we have no containing block yet. In that case, CSS says:

If the containing block's width depends on this element's width, then the resulting layout is undefined in CSS 2.1.

So yes, adding these percentages does not negatively impact scaling, but why allow them if they add no value? Am I missing a potential use? How would SVG content documents be improved by allowing percents in this case?

2. Allow any absolute unit for width and height, not just "pixels" (whatever "pixels" happens to mean). This seems like a fair point. On the other hand, no one should ever do this. But they shouldn't do it with pixels just as much as they shouldn't do it with inches (or as the French say "centimeters"). It's really horrible. Not sure I want to expand this capability, and since it is a SHOULD anyway, other units could be used if the content creator (mistakenly!) thinks they really need to.

3. Drop the reference to x & y when using x, y, width, and height to calculate the ICB. Sure? I what they are supposed to mean. Does it position the ICB in the viewport? Maybe someone wants a bit of a border around the svg, so they set the x & y position in a bit? But wow, never do that. I doubt it works.

Honestly, the more I look at this, the more I want to change this to viewbox is required, x, y, width, and height are forbidden. For now, my instinct is to say "if it ain't broke, don't fix it". Are either content creators or reading system implementors asking for this? What are their use cases?

[rdeltour]

1. Allow percentage values for height and width in the svg element in svg content documents. What would it mean?

Fortunately –and despite the complexity of how this works– the SVG spec is quite precise about this (as far as I understand), and is the browser implementations have good interoperability.

So given this:
<svg ... viewbox="0 0 100 50" width="50%" height="100%"> ... </svg>
when I display this on a device that is 800 pixels wide by 1200 pixels tall, how big should the svg be? 800x600? 1200x400? 400x600? I am not sure what the answer would be, and in any case the percentages are likely undefined.

The SVG would be 400px wide and 1200px tall. You can test this with the following SVG, opened in a browser and setting the device size from the developer tools.

<?xml version="1.0" encoding="utf-8"?>
<svg version="1.1" xmlns="http://www.w3.org/2000/svg" viewbox="0 0 100 50" width="50%" height="100%">
    <desc>Test SVG</desc>
    <rect x="0" y="0" width="100%" height="100%" fill="red" stroke="none"/>
</svg>

I'm no SVG expert, but I think this comes from the definition of the initial viewport:

The initial viewport's width, must be the value of the width presentation attribute on the outermost svg element

@bduga

So yes, adding these percentages does not negatively impact scaling, but why allow them if they add no value? Am I missing a potential use? How would SVG content documents be improved by allowing percents in this case?

and

Honestly, the more I look at this, the more I want to change this to viewbox is required, x, y, width, and height are forbidden. For now, my instinct is to say "if it ain't broke, don't fix it". Are either content creators or reading system implementors asking for this? What are their use cases?

My own feeling is that this section is overly restrictive, and doesn't respect the priority of constituencies. SVG content is more often than not produced by authoring tool exports, so we should be as permissive as possible on what we accept.

That said, I don't claim to fully understand this section, nor the related sections in the SVG spec. And this is another area where usage data would help making an informed decision 😉

[iherman]

The days when I did a lot of SVG are long gone, but I try to remember (without the FXL background). So I believe that:

• @rdeltour yes, your analysis is correct. The width and height attribute values will give you the size of the SVG "canvas", and the percentage in the <svg> element refers to the available display area.

• There is one thing that seems to be missing from the discussion, though. The effect, in your example, is that the resulting graphics will be distorted because the aspect ratio of your canvas will actually change. For any graphics within the SVG the real aspect ratio of the display is invisible; any percentage within the graphics refers to the logical coordinate system, ie, '0 0 100 50' (as defined by the viewbox attribute).

• If the <svg> element does not include the width and height attributes, then distortion will not happen. In that case the user agent is supposed to rescale the graphics uniformly, if necessary, to place the graphics in the available space without changing the aspect ratio. (You can actually control the exact rescale of the graphics using the preserveAspectRatio attribute. What I said is the default behavior.)

All this under the control of @rkwright who knows more about SVG than I will ever do...:-)

[rdeltour]

And by the way, this issue was created since we're implementing these rules in EPUBCheck v4.2.0.

EPUB 3.0.1 only said:

For SVG Content Documents, the ICB dimensions must be expressed using the viewBox attribute.

So all these new RECOMMENDED and SHOULD rules will trigger warnings, where none were reported before. We could "not fix it" by ignoring these, but then why put'em in the spec? 🤔

The very example used in EPUB 3.0.1 would trigger such a warning, as it doesn't comply to the rules in EPUB 3.2:

<svg xmlns="http://www.w3.org/2000/svg"
     version="1.1" width="100%" height="100%"
     viewBox="0 0 844 1200">
   …
</svg>

The "Sous le vent" EPUB 3 sample would trigger a warning too.

I'm basically concerned that this section is another source of these small backward incompatibilities, which will start being noticed when EPUBCheck 4.2.0 is out.

[rdeltour]

@iherman

• There is one thing that seems to be missing from the discussion, though. The effect, in your example, is that the resulting graphics will be distorted because the aspect ratio of your canvas will actually change.
• f the <svg> element does not include the width and height attributes, then distortion will not happen.

I'm not sure I understand.

Consider this document, adapted from an example in the SVG viewBox section:

<?xml version="1.0" standalone="no"?>
<svg
     viewBox="0 0 1500 1000" preserveAspectRatio="xMidYMid" width="100%" height="100%"
     xmlns="http://www.w3.org/2000/svg">
  <desc>Example ViewBox - uses the viewBox
   attribute to automatically create an initial user coordinate
   system which causes the graphic to scale to fit into the
   SVG viewport no matter what size the SVG viewport is.</desc>
  <!-- This rectangle goes from (0,0) to (1500,1000) in user coordinate system.
       Because of the viewBox attribute above,
       the rectangle will end up filling the entire area
       reserved for the SVG content. -->
  <rect x="0" y="0" width="1500" height="1000"
        fill="yellow" stroke="blue" stroke-width="12"  />
  <!-- A large, red triangle -->
  <path fill="red"  d="M 750,100 L 250,900 L 1250,900 z"/>
  <!-- A text string that spans most of the SVG viewport -->
  <text x="100" y="600" font-size="200" font-family="Verdana" >
    Stretch to fit
  </text>
</svg>

The presence of width and height do not affect the aspect ratio (note that I explicitly set the preserveAspectRatio attribute to its initial value, but the attribute could be removed to the same effect).

In this example, changing width to any percentage lower than 100% has the effect of rendering the graphics to a portion of the available space. The values 100% and auto have the same effect as an absence of height and width.

Doesn't it mean that we should at least allow width and height attributes with values "100%" and "auto"? Am I missing something?

If our intent is to use the maximum available space without distorting the graphics, then in my understanding the rules should be:

• SHOULD have a viewBox attribute
• width and height attributes SHOULD NOT be absolute lengths

[iherman]

@rdeltour, I must admit, I do not understand it either.

However, something may be fishy. Indeed, if I look at the original examples in the SVG document (that you reused) (which are identical in the SVG2 version), and I take the example:

<?xml version="1.0" standalone="no"?>
<svg viewBox="0 0 1500 1000" 
  width="150px" height="200px" xmlns="http://www.w3.org/2000/svg">
  <desc>Example ViewBox - uses the viewBox
   attribute to automatically create an initial user coordinate
   system which causes the graphic to scale to fit into the
   SVG viewport no matter what size the SVG viewport is.</desc>
  <!-- This rectangle goes from (0,0) to (1500,1000) in user coordinate system.
       Because of the viewBox attribute above,
       the rectangle will end up filling the entire area
       reserved for the SVG content. -->
  <rect x="0" y="0" width="1500" height="1000"
        fill="yellow" stroke="blue" stroke-width="12"  />
  <!-- A large, red triangle -->
  <path fill="red"  d="M 750,100 L 250,900 L 1250,900 z"/>
  <!-- A text string that spans most of the SVG viewport -->
  <text x="100" y="600" font-size="200" font-family="Verdana" >
    Stretch to fit
  </text>
</svg>

(note that the width and height are set to explicit length values). Per specification, I should get this:

However, this does not happen, neither in Chrome nor in Firefox. I get what you describe, ie:

In this example,[…] has the effect of rendering the graphics to a portion of the available space.

I should add: rendering the graphics with the 1500×1000 aspect ratio intact.

I am not sure what happens here; is this an implementation error?

@rkwright or @svgeesus can you help out here?

---

Doesn't it mean that we should at least allow width and height attributes with values "100%" and "auto"? Am I missing something?

We can allow it, but it does not have any effect. The missing width and height values defaults at 100%, per the svg spec.

[rdeltour]

I am not sure what happens here; is this an implementation error?

I think it's expected: you'd get the graphics to fit the 150x200 px box if you'd add preserveAspectRatio="none".
In any case, the box used to render the SVG is 150px wide, because of the absolute width on the outer SVG element.

We can allow it, but it does not have any effect.

Well, that's the point: these attributes have no effect, but allowing these have the direct effect of not rejecting perfectly acceptable SVG. In other word, we'd be on the good side of Postel's law and the priority of constituencies.

[iherman]

@rdeltour yes, I have spotted my mistake: the initial value of the preserveAspectRatio is not none, as I thought it was, but one of the other values (xMidYMid) that forces uniform scaling. My fault entirely. If the preserveAspectRatio=true is used, then the width=50% in the #1236 (comment) indeed re-scales as described in #1236 (comment).

I have no experience with FXL deployment and requirements, but some of your statements sound right to me. Like

…these attributes have no effect, but allowing these have the direct effect of not rejecting perfectly acceptable SVG. In other word, we'd be on the good side of Postel's law and the priority of constituencies.

but, also,

Honestly, the more I look at this, the more I want to change this to viewbox is required, x, y, width, and height are forbidden. For now, my instinct is to say "if it ain't broke, don't fix it". Are either content creators or reading system implementors asking for this? What are their use cases? [@bduga]

My own feeling is that this section is overly restrictive, and doesn't respect the priority of constituencies. SVG content is more often than not produced by authoring tool exports, so we should be as permissive as possible on what we accept.

Indeed. Why is it necessary to disallow the usage of the x/y/width/height/preserveAspectRatio attributes? A combination of width=100% height=100% preserveAspectRatio=none means that the SVG content will always fill up the full available space on the screen, with possible distortion: a strange usage indeed, but why restrict it if the author wants to do it? Mainly when considering graphics, all bets are off on what the author may want to do...

[bduga]

The problem is we are not looking at merely displaying content in a browser, we are displaying it in a reading system, and we want a vaguely reliable way for the reading system to determine the dimensions of the svg. If we start adding things that are undefined (like height 100% on the root element) that gets harder to do consistently. In general, the easiest way to deal with svg content documents in a non-borwser RS is to determine the aspect ratio, and make a webview that maximizes the size of the image, then color the letterboxing with any FXL specified background color.

@iherman I am not sure why you say:

A combination of width=100% height=100% preserveAspectRatio=none means that the SVG content will always fill up the full available space on the screen,

Where is that speced? As far as I can tell, height 100% on the root element is undefined if the ICB is not yet defined (which it can't be since these are the rules for calculating the ICB).

[iherman]

@iherman I am not sure why you say: A combination of width=100% height=100% preserveAspectRatio=none means that the SVG content will always fill up the full available space on the screen,

The spec does say that a 'none' value means scaling without keeping the aspect ratio, and the w/h set to 100% means use the full window of the browser. That is also the behavior on chrome based browsers (I didn't test on FF).

[bduga]

the w/h set to 100% means use the full window of the browser

That is the bit I am curious about. My general feeling is the CSS box model is a nightmare to understand, and I fully believe that I do not understand it, but it doesn't look like height="100%" means the full height of the "window" in the browser (not sure even what window height means). Just because one browser interprets an undefined value one way doesn't make it right. Traditionally, I have seen undefined height values mean "the full height of the viewport", or "all the remaining space in the viewport", or "0".

[iherman]

@bduga,

That is the bit I am curious about. My general feeling is the CSS box model is a nightmare to understand, and I fully believe that I do not understand it, but it doesn't look like height="100%" means the full height of the "window" in the browser (not sure even what window height means). Just because one browser interprets an undefined value one way doesn't make it right.

I agree with you on CSS:-) but this is not CSS. These are SVG-specific attributes; see https://www.w3.org/TR/SVG/geometry.html#Sizing. I could not locate the precise description that would be anything but the intuitive one ("x % of the visible area"), but here is the test file I used:

<?xml version="1.0" standalone="no"?>
<svg viewBox="0 0 1500 1000" width="100%" height="100%" xmlns="http://www.w3.org/2000/svg" preserveAspectRatio="none">
  <rect x="0" y="0" width="1500" height="1000"
        fill="yellow" stroke="blue" stroke-width="12"  />
  <!-- A large, red triangle -->
  <path fill="red"  d="M 750,100 L 250,900 L 1250,900 z"/>
  <!-- A text string that spans most of the SVG viewport -->
  <text x="100" y="600" font-size="200" font-family="Verdana" >
    Stretch to fit
  </text>
</svg>

and the behavior is identical in Chrome, Firefox, and Safari

[bduga]

I agree with you on CSS:-) but this is not CSS. These are SVG-specific attributes;

That, unfortunately, defer to CSS:

See the CSS 2.1 specification for the definitions of width and height.

Now, I have no idea what that is supposed to mean with reference to calculating the ICB for standalone SVG content documents in an epub. But viewing the sky from the bottom of this rat hole is making me lean more and more to "please don't do this because we have no idea what it means".

[Doktorchen]

width and height of 100% are simply the default values for these attributes, would be funny, if an epubcheck notes, that not setting the default values explicitly is ok, but it produces a warning, if one sets the default values explicitly. ;o)

Percentages are simply related to the available viewport for the SVG document.
For standalone it is the available part of the program window to paint something in it.
If preserveAspectRatio is not set to none, the aspect ratio is preserved, how this is done, depends on the value of the preserveAspectRatio.
SVG defines in detail what to do with viewBox, width, height and preserveAspectRatio.
No need for EPUB to note something in contradiction to the SVG recommendation and best practice.

If SVG is embedded in another document using CSS for styling, the size the element around the SVG part determines, what 100% means.
Because CSS typically does not automatically provide a defined height, either authors need to do this or is aspect ratio is preserved, height can be determined from the CSS width of the embedding element. If the aspect ratio is not preserved, CSS has a practically useless fallback, authors need to avoid by setting the height of the embedding element explicitly.

If an SVG contains some relevant text, that should be readable, I'd recommend to use width and height with units like em or ex, but never px.
Using px-values for width and height would be similar useless as px-values for font-size in CSS+XHTML.
With width and height in em and a viewBox one can ensure, that text in the SVG remains readable.

Typically for SVG cover image title and author names are large enough, that using the 100% default for width and height is ok.
This is a pretty good choice as well, if the SVG contains no (relevant) text or only a few words with pretty large font-size.

Obviously viewers/user-agents have to provide a mechanism to scroll or move/pan the document relative to the viewport. If the viewport is smaller than width and height in other units than percentages, this is unavoidable.
Additionally, if there is not attribute in the document that forbids it, the viewer has to provide a mechanism to scale the SVG manually to be able to see it completely or just in details.

For a lot of text it is better for authors and the audience to use XHTML (with the text part) with embedded SVG for the graphics.

[mattgarrish]

To try and begin whittling away at what needs to change one piece at a time, is there agreement that the recommendation to "only" use viewbox is overly-restrictive and unnecessary, thus we only need to say:

It is RECOMMENDED to use the viewBox attribute to ensure proper rescaling of the SVG Content Document, as needed.

This will retain compatibility with 3.0.1, which only defined viewbox for calculating the ICB.

(Thumb up this comment if you agree.)

[mattgarrish]

For the rest, my rereading of the old issues is that we were trying to spell out what a reading system will attempt to do in the absence of a viewbox declaration.

In that light, could we rewrite the following paragraphs as follows so authoring is only guidance:

Reading Systems SHOULD use the [SVG] viewBox attribute to calculate the ICB. The coordinate system defined in the attribute is mapped to the Viewport, keeping the aspect ratio, thereby establishing the initial containing block (ICB) in pixels [CSS2]. The result of this mapping is typically the bounds of the Viewport.

If only the height and width attributes are specified, Authors are strongly encouraged to use user unit or absolute length unit values in these attributes.

If the coordinate system is defined by the viewBox and the width/height values, the coordinate system defined by the viewBox is mapped on the boundaries as described in the previous item.

[mattgarrish]

Or we can always go back to the 3.0.1 wording that the ICB must be specified in the viewBox and continue to say nothing about what happens in its absence.

[Doktorchen]

A link in the 'toc' can point to a view element resulting in another viewBox.
A link can as well point to my.svg#svgView(viewBox(0,0,200,200)) or other variants of an svgView to get the currently intended viewBox.

Note that for preserveAspectRatio="xMidYMid slice" or other slice variants only parts of the viewBox are displayed, if the aspect ratio does not fit.
This can be quite useful for authors to provide tilings (like those from Penrose).

With 'meet' instead of 'slice' typically the rendered part of the SVG is larger than the viewBox. Depending on the align part of preserveAspectRatio there is additional visible content left, right, top or bottom to the viewBox.

Both cases show: The viewBox does not determine the containing block.

The initial containing block for an SVG document finally is not determined by the SVG document, it is the viewport, as already the CSS definition explains.
Attributes like width, height, preserveAspectRatio, viewBox only provide information, how to render (scale, translate) the SVG document on the canvas relative to this viewport.
For SVG documents this is relatively simple.

For SVG embedded as a fragment in XHTML, styled with CSS, it gets more complicated due to the interactions of the CSS box model with the different SVG model.
In this situation authors always have to keep in mind to provide enough information about the width and height of the containing block to get the intended area for the SVG content.

If the SVG document is referenced with an XHTML img element, that has itself no width and height, it gets really problematic, if the SVG document contains no width and height, trying to use viewBox and preserveAspectRatio to get some width and height for the img might be necessary, authors should avoid this.

SVG 1.1 and SVG tiny 1.2 have no CSS properties width and height for the outermost svg element, therefore the containing (CSS styled XHTML) element needs meaningful width and height.

However, to use a viewBox and only units on width and height of the root svg element (the way, SVG tiny recommendations go), is more a pretty helpful hint for authors for other reasons, not something to recommend.

Reading systems have to recognize such link issues (pointing to a view, having an svgView), have to take care of width, height, preserveAspectRatio and viewBox to render the intended part of the SVG document into the viewport, respectively the containing block.

The viewport in SVG only:
https://www.w3.org/TR/SVG11/coords.html#ViewportSpace

The attributes x and y of an svg element have no effect for the outermost svg element:
https://www.w3.org/TR/SVG11/struct.html#SVGElement
They are intended for the use of additional svg elements similar to symbol elements.
Therefore they are not related to the problem of the containing block at all.

SVG views:
https://www.w3.org/TR/SVG11/linking.html#LinksIntoSVG

SVG view element:
https://www.w3.org/TR/SVG11/linking.html#ViewElement

[bduga]

This issue is already fairly dense as it contains three issues, it would really help me to follow the discussion if we could limit it to the issue(s) at hand, specifically calculating the ICB for SVG content documents in fixed layout epub. If there are other issues with svg in epub, please open separate bugs, but please do reference them if appropriate so we can follow along.

For the comments from @mattgarrish I am fine with the first since it seems to be no change. The third (revert to 3.0.1) is fine, but seems a step backwards. For the second option, I am concerned with encouraging the use of absolute lengths since this is almost always wrong in this case (content creators have no idea how much space they have).

I think what we are trying to encourage here is a simple way to make an SVG that uses as much of the available space as possible without distortion, and allows the reading system to fill the remaining area with whatever background color was specified in the epub metadata.

As far as height being 100% by default ... sort of. It really seems like this part of the svg spec is broken. The default value of height is auto, which is then "treated" as 100%, but it is not clear what the processing model for "treat" is. As far as I can tell, in this case, 100% computes to auto. I have no idea at what stage of CSS value calculation "treat" kicks in.

[Doktorchen]

bduga, the default is 100% (of the available viewport), not auto.
width and height in SVG 1.1 are attributes, no CSS properties.
In SVG 2 maybe, there will be properties as well, but they will have the corresponding meaning.

What 100% means, depends on the media:

a) Continuous media: width and height of the viewport.
To render something, you need practically a window area on the screen you are allowed to render within with some width and height.

b) paged media (especially if the EPUB is printed on paper):
The sheet of paper has width and height, they correspond to 100% (maybe for a printer there are some additional margins).
If you print to a PDF, it has width and height as well.
For a simulation of paged media on a screen:
Either don't do it at all or require a virtual paper size as for PDF and do it the corresponding way.

Concerning fixed layout: There is for SVG not much difference to normal layout.
If an author notes for an SVG width="10000mm" height="10000mm" for example for a true scale map, the size of the output is 10 meter x 10 meter. On a screen one needs to scroll, printed on paper the best you can do is to render parts of it with redundances to several sheets of paper to allow the audience to glue it together.

If an author notes width="40em" height="6000em" you get a size depending on the preferred font-size of the current user. This might happen for example for an epic poem with additional visual effects. Would be useless to scale it down for example to the height of the screen, because nobody could read it anymore.

Scale only the SVG to the size of the viewport or the sheet of paper, if width and height are given in percentage (including the default 100% if not specified explicitly).
Note: width="200%" height="200%" is possible as well.

[rdeltour]

Thanks @Doktorchen for your valuable comments, this is really helpful.

The more I think of it, the more I feel that this is not in the realm of specification, but in the real of best practices. No? Do Reading Systems actually need something specific from the author?

[bduga]

Sorry, I might be confused about what we are talking about. My comments are specifically to epub content documents 3.2:

https://w3c.github.io/publ-epub-revision/epub32/spec/epub-contentdocs.html#bib-svg

Which in turn normatively references SVG here:

https://w3c.github.io/publ-epub-revision/epub32/spec/epub-contentdocs.html#bib-svg

Which has this link:

https://www.w3.org/TR/SVG/

That seems to be SVG 2, so our normative reference is not to 1 or 1.2. That spec seems to discuss height and width here:

https://www.w3.org/TR/SVG/geometry.html#Sizing

That section defines no default values, instead of a value description section it has the text:

See the CSS 2.1 specification for the definitions of width and height.

It also has the text:

The value auto for width and height on the ‘svg’ element is treated as 100%.

In the reference to CSS 2.1, in the text for height is a link that points at:

https://www.w3.org/TR/CSS21/visudet.html#propdef-height

That clearly defines the initial value to auto. Of course, a browser default could change that, so it is vaguely possible that the default in browsers for the svg element is 100%, but it doesn't change the computed value of 100% in this case being auto.

Am I wrong about the specs in question? All these links create a maze of twisty paths. If only there was a linear reading order ...

[mattgarrish]

If the second option to remove authoring requirements doesn't work, how about we strip all of those paragraphs and simply say that the ICB must be specified either using the viewBox or height/width attributes, with viewBox recommended, and leave the details and rendering to the reading systems?

[Doktorchen]

bduga - SVG 2 is not a recommendation yet, only SVG 1.0, 1.1, 12 tiny.

And the SVG2 candidate recommendation seems to be borked somehow, if subsections are indicated to be 'Editors Draft' - this seems to be not ready to use now.

But if it notes, that CSS auto is 100% for width and height, it is still the same as SVG 1.1 etc.

mattgarrish: Helpful for authors and audience would be something, that results really in something readable, especially no naive scaling of the viewBox or width or height to 100% of the viewport, if authors do not note this with width and height in percentage.

In my test ensemble I was surprised, that even XHTML+CSS fixed layout documents are scaled to 100% of the height of the viewport in some viewers, effectively resulting in unreadable text. This might be a result of providing size information in px, instead of em or ex together with naive scaling without taking into account readability of text content.
Does it really help, that the audience has to unzip fixed layout EPUBs to view documents in browers directly to get some readable presentation (in doubt switching off CSS interpretation or modifying the source code?)
If authors really want to get this mentioned epic poem in fixed layout, they need to switch to such an SVG with width="40em" height="6000em".
And even with added viewBox="0 0 40 6000", it is important for the audience, that they can read those ~6000 lines of text, not just getting a vertical line ;o)
A hint/clarification for developers of viewers would be important for the audience here.

[bduga]

SVG 2 is not a recommendation yet, only SVG 1.0, 1.1, 12 tiny.

Ok, but our normative reference is to 2.0. That might be an error, and we might want to normatively reference a different spec. But that is a different issue. Likely one that needs to be resolved before we can even start to discuss this, though I think we were deliberate in our choices for normative references.

But if it notes, that CSS auto is 100% for width and height, it is still the same as SVG 1.1 etc.

It notes it in a highly underspecified way. Does it mean a specified value of auto turns into 100%? What happens if the computed value is auto? Does it also turn into 100%? Do you have to recompute in that case? Very confusing, and likely worth raising a bug in the svg group.

As for a 6000 line epic poem as a single svg content document in a fixed layout epub, that will never work. While some readers might allow you to scroll, many will not. Even for reading systems that would allow you to scroll that content, location information would probably be lost.

[dauwhe]

Ok, but our normative reference is to 2.0. That might be an error, and we might want to normatively reference a different spec. But that is a different issue. Likely one that needs to be resolved before we can even start to discuss this, though I think we were deliberate in our choices for normative references.

@bduga, that has been discussed in #1219. We added language to the spec around this. And I talked to Amelia the other day, who says SVG2 better describes what browsers actually do.

[Doktorchen]

The EPUB3.2 draft notes: 'This specification does not reference a specific version of [[SVG]], but instead uses an undated reference'. Therefore any version should be ok with this.
About the SVG version: 1.0, 1.1 and tiny 1.2 have a version attribute. If set, this applies, because this is, what the author used to create it and the document relies on. If authors do not note a version, the document has no time independent meaning, SVG 2 may apply, when it becomes a recommendation, in the future it could be something completely different. If an older viewer tries to interprete it, version 1.1 may apply too, because this will be typically the current version for current and older viewers.

But because these new property approach in SVG 2 referencing CSS can cause a lot of backwards incompatibilities, it is of course a good idea to ask the SVG working group about it, in doubt reporting a bug (maybe the mailing list is better, because the subsections are indicated only as editor's draft).

Directly in a browser width="40em" height="6000em" causes no trouble, if it does for EPUB viewers, it is maybe useful to reuse/study libraries from browsers to get it right.

But even if EBUB3.2 indicates, that for fixed layout everything has to be scaled down until it fits into the viewport, no matter what authors want or specify, authors at least know, that they cannot use fixed layout for their project. If it does not even work for normal layout in some viewer, they can at least give a hint to the audience with examples of viewers, which do not have the problem.
These are not good solutions, but still better than unexpected behaviour due to undefined situations.

[dauwhe]

I propose that we close this issue, as we have reverted to EPUB 3.0.1 language:

For SVG Fixed-Layout Documents, the ICB dimensions MUST be expressed using the viewBox attribute [SVG].

I don't think we'll accomplish anything by pursuing this further in the context of EPUB 3.2.

[murata2makoto]

@dauwhe 3.1? Do you mean 3.2?

[dauwhe]

@dauwhe 3.1? Do you mean 3.2?

Sorry. Yes. Fixed in above comment.

[dauwhe]

Closed via CG exhaustion