Re: Default size and autodetection (SVG 2?)

Hi Dr. Olaf,

On Sat, Jul 18, 2015 at 7:11 PM, Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
wrote:

> Hello,
>
> to get your SVG content scaled to the viewport, just use the attribute
> viewBox
> and maybe as well preserveAspectRatio on the root svg element.
> Alternatively you can use width and height with no percentage values.
>
> If you note no width and height, they automatically become both 100%
> of the available viewport.
> Obviously neither a program nor humans can know, with part of the
> canvas you consider to be relevant, therefore if you provide no
> information about it, you cannot expect, that anybody can scale
> automatically ;o)
>

I can't agree here. The program that is able to draw SVG obviously knows
the borders of the image. It is easy for such  program to calculate the
dimensions of this SVG as 10x10

    <svg xmlns="http://www.w3.org/2000/svg">
      <rect width="10" height="10"/>
    </svg>

But it is not easy for me to update the width and height properties of the
image with that special software. This diminishes the usefulness of SVG
as a markup for manually constructing images and makes it more like
human-readable serialization format of vector data for big applications.

My expectation for the browser to treat that box as 10x10 image
(especially when I use it with <img> tag, but it may be true for other
embedding means for consistency).


> For example the artist Kasimir Malewitsch put a black square on the
> canvas already, but the position matters, it cannot be guessed
> automatically
> just from the square.
> Sigmar Polke created a painting with a black corner and a text about
> the black corner, why he had to make it black and a corner.
> The relation to the visible part of the canvas cannot be guessed
> automatically.
> Therefore do not expect this from simple programs, if we cannot do this
> for simple artworks ;o)
>

I see that you're speaking about canvas. Why canvas size is not 10x10
in my box? This is a a thing that is most obvious to me. If SVG defines
canvas and viewport (which seems out of scope to me for the basis of
vector graphics file format), then why it can not make it match the
dimensions of the image by default?


> If you note with the viewBox, which part of the (infinite) canvas is the
> relevant one, simple programs can scale this area automatically to the
> available viewport. You do not need to set width and height explicitly.
> Obviously if your (X)HTML:img element provides no information about the
> size of the viewport (attributes width and height) it becomes difficult.
> According to SVG it should be 100% of the available viewport, maybe that
> of the embedding document as well, but this is not clearly defined and
> (X)HTML does not define either, how much the img is, if there is no with
> and
> height noted and such information cannot be derived from the referenced
> image either. Therefore authors have to care about this either with width
> and height for the  (X)HTML:img/object or within the SVG file or with the
> related CSS properties.
>

Thanks for the explanation. I guess that's the basics that everyone here
should be aware about, but I am not affected the by The Curse of Knowledge
(yet), so I hope this provides some useful feedback for refreshing the
matters.

I don't completely understand why a sophisticated approach was taken to
introduce "the (infinite) canvas". Maybe it is like math - can be beautiful
in
theory, but really hard to deal with in real world. Like we all know that
the Lisp
is inherently beautiful and XSLT is turing-complete, but for real world
problems
most people people choose something Python + Jinja2 (or PHP for both).

I see the point of conflict here is that SVG specification assumes that
program
that is rendering SVG, can not detect the size automatically if it is not
set
explicitly. This looks to me as an anti-pattern of premature optimization.
Can
it be confirmed (and designed for SVG2) that most programs that deal with
SVG (and especially those that render it) are able to calculate the real
image
size automatically?

I guess that if explicit width and height doesn't match the real size of
content,
SVGs start to look distorted. So, basically people who are writing images
manually (or using the scripts) have no chance to get their images look
right
in the browser. They **will have** to use JavaScript after loading the SVG
to detect the dimensions and fix the container box. This is the problem I am
trying solve and the reason I came here. I wish I could to use SVG
declaratively without additional scripting. Because even if I use JS to auto
detect and adjust the dimensions, it doesn't work with <img> tag, because
width/height (and access SVG markup) is lost in this case on loading. That's
already too much details to care about.

Would be nice if SVG2 could address that use case.


> I think, these 300x150 come from an intenionally stupid CSS rule, not
> directly
> related to SVG or (X)HTML. The rule is stupid enough to ensure, that
> authors
> care to provide more meaningful information about the size of the graphics,
> and this can be given with attributes width and height for
> (X)HTML:img/object
> as well.
>

I think majority of standard for humans failed, because they were written
like for
computers. We've seen that happened with XHTML - yes, it is still here, but
the
trend is HTML5. That's because XHTML put too much pressure on authors.

Unfortunately, "don't make me think" is the motto of new century and the
main
design guideline for many interfaces. So I think of SVG as of interface that
works through the keyboard to code the picture that only exists in my head
through the text into the vector graphics on the screen.


> About namespaces (xmlns) - well this is a simple, efficient and very
> important
> feature of XML to give a relation to a defined meaning for elements (and
> attributes). And it is older than SVG or XHTML.
> Without you have only meaningless tag soup.
> Without rect does not necessarily mean a rectangle.
> Within another XML format, for example a medical markup language for
> graphical representation, it could be a container for rectal issues as
> well -
> how to distinguish without namespaces?
>

The mime type. In my specific case, when I load <img src="box.svg"/>
the mime type is guessed from extension. If it is not, I can set it
explicitly.

If we're speaking about (X)HTML and web, my expectation for <svg> tag
content to be "image/svg+xml" is the same as expectation for <script> to
be "text/javascript" be default.


> And to distinguish will be quite important typically both for
> SVG authors and those using the medical markup language for graphical
> representations and even more for those using both in one document ;o)
> It is mainly a service both for authors and the audience to get this right
> and meanigful with namespaces.
>

"Namespaces are one honking great idea..." but it will help to use them
explicitly only when there is a real need to change the defaults.


> Without you have only meaningless tag soup.
> You can see already with this example - it is pure and established
> practice,
> no academic theory at all ;o)
>

This practice comes from the book on XML, which is a product of academic
theory. =)


> Have fun with SVG (and mixing fragments from different namepaces)
>

I am already having fun with 1px border between my svg.box and enclosing
<object> tag in Firefox (Chrome is ok), but that's maybe better discussed in
parallel thread.
-- 
anatoly t.