naturalHeight and naturalWidth

One idea I would like to see as part of new <graphics> element (if this is the way things go) is some provision for css-resizing the rootmost element while maintaining a height/width ratio.

preserveAspectRatio is good for fitting a viewbox or <viewport> to the root box, but not for for sizing that box. E.g. I want to declare a block-level <graphics> element, with height and width attributes declared in pixels, just like an <img>, and if one of its dimensions is constrained by css min/max properties, I want the other dimension to be calculated based on the proportion implicit in the dimension attributes.

This isn't specc'ed anywhere that I know of, but browsers figured it out for <img> elements a long time ago. And it works, everywhere, everyday, in every responsive design. In fact, responsive designs wouldn't exist if it didn't. It's hair-pullingly annoying that "scalable vector graphics" still aren't actually all that scalable in an in-flow situation in a responsive html document (unless you use a container).

The problem is usually (though not always) height. SVG heights don't expand or shrink to contain their contents like normal html elements. So, as SVG enters the html namespace more and more, some kind of different sizing mechanism is required.

I've ranted about this recently here, and (having been totally ignored) I'm back for more, this time with concrete suggestions. Either:

1) Adapt "naturalWidth" and "naturalHeight" attributes from the <img> element, and use for <graphics>. The spec also sometimes calls these "intrinsic" dimensions. The conceptual fit isn't exact, because there's no asset with native pixel dimensions being downloaded, but it's close enough, and familiar already. Basically just copy all the height/width IDL from the <img> spec. I think this is the way to go.

2) Kick the problem over to CSS, and require a UA stylesheet that gets proportions of the <viewport>. I don't like this idea much. It's confusing--and likely to cause unnecessary debates in bug reports.

3) Add a "constrainedProportion" or somesuch attribute, representing (height/width) which takes a number. So authors could write:

    <graphic width="100%" constrainedProportion="2.5346" style="display:block"></graphics>

This has the advantage of steering clear of the existing SVG height/width miasma, and the doctrinaire question of what "intrinsic" really means for vectors, at the cost of introducing more terminology.

*********

Thinking even bigger and better, any of these three patterns could be generalized to non-root svg elements included in html directly, e.g.

    <div>
        <path d="" width="500" height="200" style="display: block; max-width: 100%">
    </div>


Screw the legacy container requirement entirely. No <svg>, no <graphics>, no namespacing, no verbose DOM attribute pollution with stylistic things that really belong in CSS. Fully responsive. All sizing handled through css, just like an <img>. This is the holy grail of simplicity for authors. (Cameron, that's a "yes" on your issue #12.)

Received on Friday, 9 August 2013 00:52:57 UTC