W3C home > Mailing lists > Public > www-svg@w3.org > January 2013

Re: SVG 2 Features and Approach

From: Jelle <pjmulder@xs4all.nl>
Date: Mon, 07 Jan 2013 19:18:05 +0800
To: www-svg@w3.org
Message-ID: <op.wqjgcfo1xr72zo@action-pc>
Hello all,

As I didn't know where to start but felt in a bit of a hurry, I sent this  
message to Doug who kindly pointed me in this direction. I am forwarding  
it now to the correct place with some additional info.

On Mon, 07 Jan 2013 03:51:41 +0800, Doug Schepers <schepers@w3.org> wrote:

> Hi, Jelle-
> I always suggest that people send their suggestions, thoughts, and  
> comments on SVG to the www-svg@w3.org mailing list, rather than to me  
> directly; I don't want to be the single point of failure for good  
> conversations about how to improve SVG. :)
> So, please do send this email to that list instead.
> But here are my initial thoughts...

Original posting including Doug's reply.

> On 1/5/13 11:17 PM, Jelle wrote:
>> Hello Doug,
>> I guess I'm a tad late, but as Tav posted all the nice links to the new
>> SVG 2.0 proposal, I though I might send you this message and see if
>> there is any response to it.
> Forgive me, but I am missing the context. Where did we meet? Was it at  
> SVG Open?

Sadly we've never met in person, I've been in China for quite a while now.  
I taught web design here in Chongqing, China which involved a heavy use of  
SVG as the most probable technology for anything future related. And they  
are design students so they can learn to read and write code with strong  
interactions, SMIL animation and the like. HTML always is a bit abstract  
and dull for them and me as well to be honest.

>> Proposal 1: minimum and maximum sizes
>> One of the capabilities of SVG being scalability, one of the things I
>> would love to see is the setting of minimum and maximum sizes for
>> objects. It's nice to scale things down to fit into a window, but you
>> can only scale something down up to a certain level the loss of detail
>> is too much and things become unreadable as we're constrained to a
>> minimum pixel or dot size.
>> My proposal is to optionally add a minimum and maximum size to objects.
>> For example <g width="100%, 600px, 1200px" /> and <Text
>> font-size="1.4em, 14px, 24px"/>  That would allow for dynamic layouts
>> with an insurance of readability. Especially in combination with the new
>> text flow mechanism, it would allow for very powerful and flexible text
>> layout without the problems that HTML has. Nice thing about this method
>> is that it doesn't add much data, as you could just omit values if you
>> don't need them, the method is used in other parts of SVG and it's
>> readable.
>> Use case
>> Text flows with minimum constraints, dynamic layouts with objects
>> scaling to a minimum acceptable view size. Great for web and page
>> layouts with unlimited x or y depth.
> I think what you're asking for can be accomplished with using CSS Media  
> Queries. Here's an example where I alter the image from the same SVG  
> file to add or remove detail based on where it's used (down-arrow to see  
> the bullet points), completely declaratively:
> http://www.w3.org/2010/Talks/06-schepers-atmedia/media-queries.html
> Let me know if that's the sort of thing you have in mind.

It is a bit similar, but not quite. This is does a reordering of objects  
untill a constraint is met. It doesn't rescale the text, to a smaller or  
bigger size. Take for example the situation that we have with all the  
screen formats on mobile phones. Some are landscape oriented, while others  
are portrait. Now we solve this problem by creating two layouts and  
switch. If the poor sap has a screen res of 320 x 200 our user will not  
see a bloody thing as our 14 px text has rescaled to a measly 3 or 4 px as  
it was designed with 1024x768 in mind. My proposal is to have the minimum  
trigger a scroll bar once the size of the text meets a 14px minimum or for  
those blessed with large screens, but not fully myopic a constraint at  
24px maximum. A forseeable problem would be when people fill up a document  
with tonnes of such constraints, that could become a bit processor heavy.  
But surely there's an elegant way around that.

This would allow for rescaling downwards of some objects, but not others.  
I am thinking about logo's, text on maps, text in columns or headlines,  
basically anything that you want to be visible and readable at low  
resolutions. For the max, the scope is the other way. I really don't need  
a 1920x1600 monitor filled with a complete page. Okay,.. they can just  
scale down the window of my browser, but it might be nice from a design  
point of view to take those poor window jockeys a day off. they could  
always override the setting with zooming in and out using the browsers  

>> Proposal 2: Special container Object or alignment rule for objects.
>> An object container similar to DIV would be extremely practical. The
>> nasty thing of DIV's is that everything in it is constrained to it's
>> borders and no direct interaction to other object outside it are
>> allowed. If you want your drop down menu to show outside of a DIV header
>> for instance, you have to create a new DIV somewhere and then you can
>> fill that with some content.
>> SVG doesn't have the problem, but it would be very useful to have some
>> container object, that can align to other objects with a specified ID at
>> a certain offset.
> If I understand your proposal correctly, I recently proposed a different  
> mechanism that has some of the same outcomes. I suggested that we allow  
> any graphics element to be the parent of other graphics element, and  
> that the positioning of the child would depend upon the parent.
> For example:
> <rect id="rect-1" x="10" y="50" width="100" height="30">
>   <rect id="rect-2" x="10" y="30" width="100" height="30"/>
>   <rect id="rect-3" x="10" y="60" width="100" height="30"/>
> </rect>
> Rect-2 and rect-3 would both have an effective x value of 20 (rect-1's  
> 10 + their own 10), and an effective y value of 80 and 110,  
> respectively. This would change accordingly if rect-1 were moved around.  
> Thus, they would be positioned like a submenu of a parent menu item.
> This is a very simple relative layout mechanism (specifically, a one-way  
> constraint layout, computationally very easy).
> The other stuff you've mentioned harkens more to more complex layout  
> options for SVG, which I think many people would like to see, if it can  
> be done performantly.
> Regards-
> -Doug

>> The names of the attributes are just as an example what attributes would
>> be needed, I'm aware of "-" not being a very usable sign in code.
>> i.e. 1)
>> <container ID="footer" align-to="body" width="100%, 600px, 1200px"
>> x-align="top" y-align="left" x-offset="10%, 10px"/>
>> ** Note
>> width="100%, 600px, 1200px" for minimum and maximum constraints
>> x-offset="10%, 10px" would mean 10% offset normally with a minimum of  
>> 10px
>> i.e. 2)
>> <container ID="submenu" align-to="menu" width="100px" x-align="top"
>> y-align="left" x-offset="20px" y-offset="20px">
>> <use xlink:href="buttons.svg#button1>
>> </container>
>> <container ID="submenu1" align-to="submenu" width="100px" x-align="top"
>> y-align="left" x-offset="20px" y-offset="20px">
>> <use xlink:href="buttons.svg#button1>
>> </container>
>> ** Note
>> An easy way to create submenu's
>> i.e. 3)
>> <container ID="sub" align-to="main" width="100px" x-align="middle"
>> y-align="middle" x-offset="20%" y-offset="100px">
>> <use xlink:href="images.svg#image1>
>> </container>
>> <container ID="sub1" align-to="sub" width="100px" x-align="top"
>> y-align="left" x-offset="20%" y-offset="100px">
>> <use xlink:href="images.svg#image2>
>> </container>
>> i.e. 4)
>> <container ID="column" align-to="header" width="60%, 600px, 1200px"
>> x-align="top" y-align="left" x-offset="10%, 10px"/>
>> <container ID="ad" type="array" align-to="column" width="30%, 300px,
>> 600px" x-align="left" y-align="left" x-offset="10%, 10px"/>
>> ** Note
>> The type="array" would mean that the container if it does not meet the
>> constraints and is not placeable to the right of the column object in
>> the screen it gets moved under the column. Granted,.. a bad example
>> maybe of good layout, but the object gets displayed.
>> i.e. 5)
>> <container ID="compass" type="float" x="10%" y="10%" width="10%, 200px">
>> <use xlink:href="ui_objects.svg#compass"/>
>> </container>
>> ** Note
>> The type="float" means the object will always stay on screen.
>> All of this can be created in script as well, but would be useful
>> additions to SVG and make the life of designers a bit easier.
>> Regards,
>> Jelle Mulder

Using the example of Doug here, that would render the same way. It will  
have to be made clear to people they cannot use the "-" etc. anymore in ID  
names. If this method can be used with parent-child etc. it would almost  
completely settle the issues I want to address with a container. But maybe  
it would be easier to use the "-" as a connector char to relating objects.  
That would allow for more flexible coding in case you want to add an  
option in a menu or something like that. It would certainly allow for  
things like diagrams made easy, if there would be added an angle and  
rotate to this. You could use the angle to make things right align or left  
align to the parent object. This would be a great way to create relations  
between objects and keep them logically ordered in the code.

<rect id="rect1" x="100" y="30" width="100" height="30"/>
<rect id="rect1-rect2" x="100" width="100" height="30" angle="+15"  
<rect id="rect1-rect3" x="100" width="100" height="30" angle="+15"  
<rect id="rect1-rect2-note" x="50" width="100" height="30" />

I was wondering if a similar relation could be made with text, so that you  
would be able to create text flowing from one column into the other  

<text id="text1" x="100" y="30" width="100" height="30">
Some text here

// to clear any styling of the quote here tell the style to inherit of the  
object related to.
// would be a really nice way to clear up the readability of inheritance  
of attributes as well.

<text id="text1-text2" x="100" width="100" height="30" angle="+15"  
<use xlink:href="about.svg#quote" style="text1-inherit"/>

<text id="text2-text3" x="100" width="100" height="30" angle="+15"  
More text and a bunch of TSPAN elements

// this text would be added as next in Z-order AFTER the content of  
text2-text3, unless there is some
// work on forcing z-orders I read about in the notes. To mind springs  
something like z="text2+1" to add
// if you'd like to add the note after the first child of text2

<text id="text2-note" x="50" width="100" height="30">

The best part of it being that it would be easy to separate graphical  
elements and text in a single document.

Which leaves us with the float. Sure you can script it, but why not have  
it a function as it is such a widely used object in any web design and it  
would be useful in print as well.


Jelle Mulder

I would be severely disappointed if SVG fonts are taken out of the  
standard to protect the vested interests of the type foundries, pdf and  
ps. This is the only text based font type and would be a blessing for  
anyone needing to handle subsets of fonts. A whole traditional Chinese  
font is huge in any format except for SVG, it would allow for handwritten  
font types or dynamically created ones as well and the whole diacritics  
issue is something I think should be handled by the authoring software  
rather than the fonts. Those have rules of where to place things surely  
that could be solved with "fft" rules etc. in Unicodes and the according  
glyphs. It may become an unholy mess for some uses, but I guess software  
would find a solution to handling that as well. A simple keyGlyph that  
would tell any renderer what code the first letter in the alphabet is in  
the whole string should help out for wide ranged fonts as well. The whole  
concept of SVG fonts is way too cool and useful to disregard for some ugly  
binary format like Woff that only type specialist can or want to use. Font  
hinting?,.. well maybe some better rendering algorythm?
Received on Monday, 7 January 2013 14:58:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:40 UTC