Re: Default size and autodetection (SVG 2?)

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)

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)


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.

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.

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?
And even worse, what to do, if you need to mix both formats, to get the
semantical meaning from the medical markup language for 
graphical representation into the SVG document to visualise the
rectal issues to a wide audience? (or at least to those, who are interested in 
such a visualisation?)
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.
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)


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

Received on Saturday, 18 July 2015 16:12:21 UTC