CSS 3D Object Position

ED: Ties into the discussion
yesterday about images and aspect ratio
... CSS 3 has the new object fit properties
... they effect how images are hard positioned and extended in
the image tag
... it offers more than preserveAspectRatio in SVG
... because you can position the image inside where ever you
want
... use Calc even
... not sure how this will effect the decisions made
yesterday
... it will definitely effect the case for img

DH: In SVG there is the override
for perserveAspectRatio if object fit is specified

ED: This is what Opera is doing
at the moment
... this is how we've implemented it so far
... There are two things here
... do we want to have object fit and object position in
SVG
... and perhaps get rid of preserveAspectRatio

CM: Not sure about getting rid
of
... I mean we should have the properties apply to where
preserveAspectRatio applies

ED: Positioning inside a viewport
is nice
... for other things it's mostly the same
... the difference being it's a property and not an
attribute

DS: Does it solve all the same
cases that preserveAspectRatio solves or are there still uses
for preserveAspectRatio?

CM: How you can specify
preserveAspectRatio defer for an external document

ED: In most cases I think it is
more useful to have it as a property and not an attribute

DS: That would let us deprecate
an attribute that is not very well understood and not often
used

AG: defer is not defined very
well

ED: Yes, and I've hardly seen
anyone use it

DS: So we can do everything with
image-fit
... except for defer behaviour in preserveAspectRatio

CM: We could ask the CSS Working
Group if they could add this functionality into object-fit
properties

ED: For the image element in HTML
it will have an effect because the default value for object-fit
will be "fill"
... That means it will fill the entire element
... That is the same as preserveAspectRatio "none"
... I don't think that is a change from the tests we did
yesterday

CM: That's not the default
behaviour of preserveAspectRatio

ED: If you have an HTML img
element and you reference an image with preserveAspectRatio
set
... it's not clear what happens
... I think that object-fit should override

CM: In your proposal it seems
like you want to add a new value "auto" to
preserveAspectRatio

JW: In CSS you don't have the
knowledge that value is specified. The user should have to
actively do something to say that the preserve aspect ratio is
kept
... by using defer
... Without doing anything and saying that this overrides
... All reference SVG content will have their preserve aspect
ratio will be overridden

CM: You want existing content
that doesn't have preserveAspectRatio defined to render the
same as if "none" is specified

JW: Seems to me we might need a
value of "auto

DH: We might have to insert
something to say override object-fit

DS: There are circumstances that
an author would want to change the original document

DS: It would be nice to override
what the document thinks the display is

CM: Even without SVG this object
fit could effect how raster images are sized

DH: Raster images don't react to
their viewport where as SVG does

JW: Having object-fit work on the
SVG element the interaction there are even more
complicated
... because you have an actual value and it is unclear when it
would override
... which is why you'd want an "auto" value

CM: I agree, I think we need an
"auto" value

ED: The argument that was made
was you can set different defaults depending on the context it
was used
... for the Video element it has one default value, where as
the default is different for SVG

JW: It still doesn't solve the
problem that I want to defer

DS: So "auto" would be "defer" or
"fill"

CM: "auto" would mean just do
whatever do what preserveAspecrRatio means in SVG currently

DH: I'd like to have "auto" be
like "fill" or preserveAspectRatio "none"

ED: Here is the link to the test
suite which has object-fit with SVG and some other test cases;
Video, etc
... if you have feedback on this, I'd be happy to hear about
it

CM: Does that mean that "auto"
should be proposed?

ED: If we think "auto" is useful
we should go back to the CSS Working Group with that
... The other issue I want to see resolved is to have the
support for object-fit in SVG 2

JW: I still find some of these
values not intuitively obvious about that they do

CM: Do we need to talk to them
about "none" - was it dropped?

ED: It says it is
controversial
... would need a good argument about why it is needed

ROC: I'm a bit worried about it
because image sizing is already complicated as it is. It is
easy to see how to use it for raster images
... but once you apply it to SVG images it starts getting
complicated

Accessibility

DS: SVG should be accessible but
is not accessible
... problems are inconsistency between implementations and the
lack of normative behaviour of content
... There are different kind of accessibility needs
... [Goes through presentation]
... my proposal is that we undertake to have an SVG
Accessibility document that talks about how SVG can be
authored
... for accessibility
... We wouldn't be starting from scratch we will be engaging
people that already have knowledge and are already working in
the field
... There is an Australian thing call NVDA who would be
interested in working with us

CM: NVDA is open source

DS: It was installed on every
library in New Zealand

CM: Do you see us collaborating
with the accessibility groups on this

DS: We'd talk with the people
doing ARIA
... I think we should start a different mailing list for SVG
accessibility

AD: If a lot of CAD drawings and
other schematics go to SVG
... they're going to need to be accessible

ROC: SVG is not semantic and HTML
has that same problem with Canvas

DS: SVG is semantic in the sense
withing the realm of mathematics. Outside that it's not.

CM: We should take the top 10
types of graphics - information graphics
... and define ARIA roles for them
... Also include guidelines to say when doing a certain type of
document uses certain roles and don't do certain things

DS: It would be good to define
how to make accessible graphics

CM: What sort of things?

DS: Colour choices
... I feel making a general accessibility document would be
good. Perhaps the first thing to do is make one for SVG
... then extract that out
... I've seen cases where different tones were played for the a
bar chart to indicate the overall trend in the graph

CM: Sonification

RESOLUTION: We will
start an accessibility document for SVG

AG: So you'll be the editor
Doug?

DS: Yes, I can be one of the
editors. I would like to bring in other people who know the
field more deeply

CM: I would like to get in the
expertise

z-index

AD: Your proposal solves some of
the problems
... if you do enable-background="new" what do with the
z-index
... the concept of the stacking context solves this problem

DS: Would be good to have a
diagram showing the layers
... for example showing a document without z-index and then a
document with z-index
... this would be good for authors to illustrate how the layers
work in the document

JW: applying a filter to an
element cause it to create a new stacking context

Text over-flow

ED: Some proposed wording for
text-overflow in SVG
... It's basically saying if my text is too long clip it or
flow it
... This property is defined in CSS 3
... It's not defined there for SVG
... but it is something we could apply to SVG elements
... My proposal is to add to SVG text element and SVG textArea
(in Tiny 1.2)

ROC: It wouldn't take effect if
you just had a clipping thing that contains text
... If it doesn't have a width it doesn't do anything
... HTML 5 Canvas Text has something useful
... What they do is they say here's the text and here's the
width. If it's too big shrink the width
... and increase the height

ED: You can already do that with
textLength attribute
... This is different
... one of the differences is this is for blocks of text

CM: What would happen with tspans
and absolute position of glyphs

ED: Good question
... this proposal doesn't solve all of the issues
... I have at least 10 that I could think of
... So we would need to solve these
... I don't have any strong opinion on how we solve these

CM: With the CSS one what happens
when you get selection range?

ROC: Do you talk about the
placement of the glyphs with BiDi

ED: Yes, I did
... same as CSS

ROC: I'm not so happy with the
behaviour, but it is the same between the two
... CSS and SVG

ED: In order to get the ellipsis
you need to specify overflow

CM: I still think that SVG does
need some sort of layout things in it
... SVG as it is don't need to worry about overflow
property

ED: I think the ellipsis thing is
the one thing people want

AD: There is high demand for it
in the IPTV world

ED: textArea might be a bit
simpler because it already has width and height

AD: It's really ugly to do this
in script

CM: You can imagine all different
types of ways squashing the text in
... I would like to see font size adjustment to fit things

ED: That would be more a
textLength thing

CM: What happens when you have
both textLenght specified and width?

ED: If the textLength is longer
than the width you'd get ellipsis I guess

CM: I was thinking the other
way
... to ellipsis replacement first
... so you'll never get overflowing text using textLength?

ED: No, it will just squash it
up

CM: In CSS what happens with
styling of the ellipsis?

ROC: In CSS it's either you use
the style of the block which declares the overflow but it may
have changed

CM: It seems like you want to do
closest common ancestor
... but we don't need to solve these issues now

ED: I'd like to see if this can
be place in SVG 2

AD: In textArea it should wrap so
you don't show an ellipsis. But we've had feedback from editors
that it is really ugly
... they want a character by character horizontal scroll
... For the simple case where you have a login box which just
does a character by character scroll we never did that
... We had to word wrap it and they had to live with it
... It really restricts the textArea as an editable control

CM: Why not have the
functionality on text?

AD: textArea was suppose to be
flow container
... that allowed glyphs etc.
... The whole chapter is defined
... we defined all the algorithms for it
... and it was reviewed by the experts in Indesign and they
liked the model

<trackbot> Created
ACTION-3006 - Tell CSSWG that we want to meet them! In Tokyo in
June. [on Chris Lilley - due 2011-03-11].

DS: we have colocated in the past
with LGM

CL: which is in montreal this
year

DS: with SVG Open, which is in
Boston

CL: SVG Open is late this year,
and in Boston.
... two weeks later is TPAC

AG: there's one week gap between
them

DS: I think the Thursday is the
workshop, for SVG Open

CL: maybe we could have part of
the F2F before SVG Open, then part of it on Thursday/Friday
after
... so we can concentrate on feedback we get from SVG Open

DS: one other thing with SVG
Open, is that W3C is thinking about having a night, like in
Paris
... where there'll be some presentations on teaching SVG,
showcasing it, to the general public
... so that's probably going to happen the evening before SVG
Open
... I imagine either MS or W3C would be able to provide meeting
space there
... while LGM is a good opportunity to touch place with the
open source community, and is fun, I'm not sure is as critical
as SVG Open
... how many meetings are we planning on having?

CL: we are meant to attend
TPAC
... wht aabout Thursday Friday in Boston, after SVG Open
... then 2 days at TPAC

[discussion about Tokyo meeting days]

CL: we could meet on Fri June 3
with CSS WG, take the weekend off, then have our normal 5 day
meeting on the following week

buffered-rendering

JW: we discussed this a bit, roc
alex and myself
... everyone decided that some sort of user control of off
screen caching would just end up being misused, or used
improperly
... and we'd need to disable it or not recognise it
anyway
... implementations can generally detect when things are moved
around in a way that would benefit from caching
... so caching would be automatic

<pdengler> I will look into
hosting the f2f yes,

JW: one thing that will be an
issue is animations, where the start of the animation is
immediate and smooth
... that's always going to be a problem with an automatic
caching mechanism that detects motion and decides to
cache
... if you do some gesture on a webpage that should animate
things on the screen quickly, you want it to react
immediately
... the whole purpose of using offscreen caching is beause you
need responsiveness
... but you might have a couple of frames where it's
sluggish
... we used it in a previous job, but in that situation we were
able to correct misuses of buffered-rendering because this was
a closed system
... in general I think user control of offscreen caching we
shouldn't do, at this stage

DH: sounds like your situation
where it would be slow initially, on animation start, since
it's declarative animation you could detect this

JW: sometimes, but if your begin
is something.click, so in response to a user interaction, and
if you have lots of these things in the document, and you don't
want to cache them all, you still have this issue

AD: also if it's all script

DH: for declarative, you could
render the offscreen rendering on the very first sample of the
animation
... we currently recompute the world on every sample

JW: there are two parts that make
it slow
... there are the first 1 or 2 paints, when ou figure out it's
moving, which you can avoid if the animation is
declarative
... and the other one is the slow rendering into the offscreen
buffer, which you can't avoid even with declarative
animation

CM: because these are complex
objects you want to buffer?

JW: yes

AD: you could have a limit, say 1
or 2 buffered-renderings in the document, or a certain MB of
cache

ED: we've implemented it, and
already seen misuse of it
... it says in the spec that if you update the subtree, it says
you should rerender it, but it doesn't say when
... there's a bit of free room there for experimenting
... i think it will be hard to harmonize implementations
there

AD: what was the motivation for
proposing this?

JW: i occasionally hear people
requesting it
... I wanted it for one document I was writing

ED: I think it's fine for closed
systems, but not sure it's good for the web as a whole

RESOLUTION: We
won't add buffered-rendering to SVG 2 unless implementor
feedback indicates that it is needed

Connectors

DS: [presents some slides]
... connectors would be a straight line between two nodes
... you can style their appearance
... there would be a list of connectors for navigation
purposes
... they wouldn't dynamically position nodes in the graph
... no concept of weighting on edges
... it wouldn't do line routing
... it wouldn't allow automatic drag-and-drop

[rest of the presentation]

DH: seems useful

RO: it seems like a step towards
graph layout
... and edge routing

DS: you can draw the lines
yourself, the straight line is the default

CM: the part I like the most is
the automatic connection to the closest point on a shape
... the semantic part I'm not sure about, without having a
whole aria vocab

JW: regarding routing, how about
having routing points?
... yes you can have polylines

CM: would it be a separate
connector element? how about just sticking some attributes on a
<path>?

DS: i like the syntax of a
separate element

SVG Integration

DS: we have "referencing modes
for svg"
... they are ways for specifications to say they are using svg
in particular contexts
... e.g. css might use a particular referencing mode for
images
... html might use one for image and another for iframe
... it describes svg in terms of some specific capabilities --
animation, external references, [...]
... we've talked about having one or two more, but i won't go
into the individual referencing modes

RO: why not define those flags as
independent things? you might want a combination of flags
that's not one of the preset modes.

DS: we could. i did it this way
because people in the past have asked "how do I reference SVG,
what's a handy name for a set of common flags"
... so we can say it's using "secure animated modes"

CL: you could do both

RO: or you could make the flags
normative, and the modes informative

DS: yes, well the modes would be
normative, but yes
... network admins, once they understand animated script-less
svg is safe for them, they don't have to think about it any
more

[shows examples from the spec]

scribe: it also talks about
foreign content in svg
... how you can comine -- we don't explicitly talk about using
html in foreignObject, in the svg spec
... in SVG Integration we decided we'd actually talk about
that
... talking to implementors about considerations about that

DH: might be good to mention
plugins and scripts
... i think you can only have plugins in foreignObject in
svg
... maybe in the "no script" mode it would mean no plugins

DS: also talks about svg in
foreign content
... it also talks about how to extend svg
... this was so that OASIS/ODF would know how best to integrate
SVG as a first class citizen
... then we wanted to have a list of all
elements/attributes/properties in SVG
... which could be referenced by HTML
... that's all that's in there now. we've talked about other
things, compound document scenarios that Tav's talked
about
... e.g. svg as a button in an HTML page, or in an img,
etc.
... tav will help me draw up some of that
... maybe much of that should be defined by html, it seems it's
not addressing that at the moment
... it's worth pointing out specific modes if we think they are
useful, e.g. a mode that we know should be used for css
backgrounds, we should predefine it

DH: audio/video also

DS: individually, since audio is
more annoying

DH: and it's also a subset of
video, since video comes with audio

DS: earlier on we talked about
how filters would be used in html content, etc.
... but those are in their own specifications at this point

CM: and I think that's going to
work fine

DS: I agree
... ultimately I don't know if this should be a part of SVG
2
... I think it might be worth maintaining on its own

CL: I agree
... it's an interface document
... we should publish a FPWD

DS: i'd like to add the flag idea
from roc and the audio/video/plugins comments from daniel,
first
... i'd estimate probably by the end of the month it'd ready
for publication

RESOLUTION: We will
publish SVG Integration after Doug addresses
feedback

BB: [some comments about whether
to allow TimeEvents to be dispatched in animations in
SVG-as-img mode]

pointer-events processing and security

RO: [summarises the issue raised
a while ago]
... we need to have something around pointer-events
... we do need to be able to have pointer events, make things
transparent when alpha=0
... but in a controlled way
... so maybe pointer-events should consider to intersect the
entire <image> when the image is cross origin
... so elementFromPoint would always return that element, if
the coordinates were within the bounds of that image
... there is also the properites on SVGUseElement, if you are
doing cross origin using
... you want to block those