- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Sun, 22 Aug 2010 02:20:54 -0700
- To: Doug Schepers <schepers@w3.org>
- Cc: Jeff Schiller <codedread@gmail.com>, Tony Schreiner <tonyschr@microsoft.com>, Kevin Ar18 <kevinar18@hotmail.com>, Chris Lilley <chris@w3.org>, public-fx@w3.org
On Sat, Aug 21, 2010 at 2:39 PM, Doug Schepers <schepers@w3.org> wrote: > I think it's pretty clear that the intent of the SVG 1.1 spec was that those > box-model CSS properties must not apply to any SVG elements. In addition to > what the spec states on the subject, my conversations with participants from > the SVG WG at the time are unambiguous in that respect. > > The question is, is that the behavior we want? How hard or easy is it to > change that in modern SVG+HTML+CSS implementations? What is most useful and > intuitive for content authors? > > In my opinion, we could specify that some aspects of the box model apply > without screwing with SVG's coordinate-based placement system too much. > Here are my initial thoughts on some specific properties: > > ==Borders== Would a border of a child be able to have an effect on the bounding box of its parent? Otherwise, sounds fine. > ==Margin== > No effect on SVG content, but may affect HTML content around that SVG > content. So, an <svg> element with 'margin: 20px;' has a 20px gap around > the SVG content, just as if it were <img style="margin: 20px;"/> > > Alternately, maybe margin only has an effect for <svg> elements; that might > be simpler to specify, implement, and understand for content authors. It would seem kinda weird to me to have, say, a <rect> with a margin affect stuff outside of the SVG. Normally margins are bounded by the root element; CSS is very specific about that in the case of independent documents. If box-model properties are to have no effect on SVG positioning, though (a good choice), then a margin on an internal SVG element is meaningless. Margins on <svg> embedded in HTML would be just fine, and should act as if the <svg> were a replaced element, as fantasai said. (It's kinda weird that it's a "replaced element" that nonetheless has selectable structure, but whatever.) > ==Padding== So the padding is just transparent spacing between the bounding box and the border? Sounds fine, and useful. > ==Background== > A background is different than a fill. Background is much the same as > border; it is a rectangle (modulo the border-radius effects) around the > shape, based on its geometric bounding box, taking into account padding. > > By default, there is no background color, including for the <svg> element. > > SVG Tiny defines a 'viewport-fill' and 'viewport-fill-opacity'. I think > those should be deprecated in favor of 'background' properties; I have no > opinion on which should have precedence... maybe they should be seen as > aliases of 'background', if that makes it simpler. This sounds good. I suggest aliasing if possible; the only incompatibility is the CurrentColor value it accepts. (SVG's somewhat bizarre separation between colors and other paint servers has long baffled me; hopefully future work on CSS's background property will let it be fully general about paint servers. That's why we defined the <image> type, after all.) > A background raises the question of pointer events, which is also relevant > to border. Indeed. > ==Pointer Events== > Should pointer events on the border or background fire on the element > itself? I think that the default should be "no", just to be safe and > consistent with older SVG content, but I could easily be persuaded to > reverse that. Either way, there should be a new property or set of > properties that can modify this, in a manner consistent with how CSS is > defining 'pointer-events'. I'm curious about what knobs you think might be necessary here. There was a discussion on the CSS list in June 2008 about it (you've probably already seen it, thus the reference to "how CSS is defining 'pointer-events'). Doing this 'properly' could get relatively complex, though, since both borders and backgrounds can be arbitrary images which you may want hit-tested either by their simple geometry or by their per-pixel opacity. > This touches on the question, asked in a related thread, on whether the > <svg> element, by default, should be a proximal event target for pointer > events. My answer on that is a pretty firm "no"; if you want to have it as > an event target, give it a background, or change the 'pointer-events' value. So you're saying that <svg> should normally be pointer-events:none? The current SVG default is visiblePainted, and I doubt that can be changed. ~TJ
Received on Sunday, 22 August 2010 09:21:47 UTC