- From: Cameron McCormack <cam@mcc.id.au>
- Date: Fri, 4 Mar 2011 17:19:27 +1300
- To: public-svg-wg@w3.org
http://www.w3.org/2011/03/03-svg-minutes.html
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
03 Mar 2011
See also: [2]IRC log
[2] http://www.w3.org/2011/03/03-svg-irc
Attendees
Present
+1.649.363.aaaa
Regrets
Chair
Cameron
Scribe
Anthony, Cameron
Contents
* [3]Topics
1. [4]CSS 3D Object Position
2. [5]Accessibility
3. [6]z-index
4. [7]Text over-flow
5. [8]Next F2F
6. [9]buffered-rendering
7. [10]Connectors
8. [11]SVG Integration
9. [12]pointer-events processing and security
10. [13]rechartering
* [14]Summary of Action Items
_________________________________________________________
<trackbot> Date: 03 March 2011
<tbah> OK, thanks.
<anthony_nz> Scribe: Anthony
<anthony_nz> ScribeNick: anthony_nz
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> [15]http://testsuites.opera.com/object-fit/README
[15] http://testsuites.opera.com/object-fit/README
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> [16]http://dev.w3.org/csswg/css3-images/#object-fit
[16] http://dev.w3.org/csswg/css3-images/#object-fit
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
<ed> [17]http://testsuites.opera.com/object-fit/
[17] http://testsuites.opera.com/object-fit/
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> [18]http://testsuites.opera.com/object-fit/
[18] http://testsuites.opera.com/object-fit/
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
ED: I'd say it's easier to use than preserveAspectRatio
ROC: If it's just an override it's not so bad
RESOLUTION: SVG 2 will require object-fit and object-position
<scribe> ACTION: JWatt to Gather up issues regarding object-fit and
it's applied to SVG and email CSS Working Group [recorded in
[19]http://www.w3.org/2011/03/03-svg-minutes.html#action01]
<trackbot> Created ACTION-3001 - Gather up issues regarding
object-fit and it's applied to SVG and email CSS Working Group [on
Jonathan Watt - due 2011-03-10].
<heycam> roc,
[20]http://dev.w3.org/SVG/profiles/1.1F2/test/status/implementation_
matrix.svg
[20] http://dev.w3.org/SVG/profiles/1.1F2/test/status/implementation_matrix.svg
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
<jwatt> [21]http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/z-index
[21] http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/z-index
AD: main problem is how it would fit in the rendering model
... If you introduce a stacking context when a z-index is specified
... it solves the problem just fine
ED: I haven't read all of the details
... I think it makes sense to add z-index support rather than
layered-g
AD: If you don't specify z-index then your performance impact is
nothing really. Only if you specify z-index you need to walk the
tree twice which isn't too bad
DS: It's better from an authoring perspective
AD: I wouldn't bother putting any note in until it's shown to be a
problem
... or a performance hit
... but I wouldn't expect there to be a performance hit
DS: This is an SVG 2 thing right?
JW: Yes
CM: If there are technical details we can work them out when we are
writing up SVG 2
RESOLUTION: We will add Jonathan Watt's z-index proposal to SVG 2
JW: From what I remember CSS talks about how to deal with the
background
... and we're not going to get stroke and fill on different levels
CM: The syntax of the property is just the same as CSS?
JW: Yes
... same definition, but with simplified instructions of how it
works
<scribe> ACTION: JWatt to Add z-index proposal to SVG 2 [recorded in
[22]http://www.w3.org/2011/03/03-svg-minutes.html#action02]
<trackbot> Created ACTION-3002 - Add z-index proposal to SVG 2 [on
Jonathan Watt - due 2011-03-10].
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>
[23]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Text-ov
erflow
[23] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Text-overflow
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
DS: This is something that a lot of people want solved
AD: I'm strongly in favour of text-overflow
RESOLUTION: We will add text-overflow in SVG 2
<scribe> ACTION: Erik to Add text-overflow in SVG 2 [recorded in
[24]http://www.w3.org/2011/03/03-svg-minutes.html#action03]
<trackbot> Created ACTION-3003 - Add text-overflow in SVG 2 [on Erik
Dahlström - due 2011-03-10].
CM: The whitespace property, does that have any effect on us?
ED: No
CM: Can we move away from using XML whitespace and use the
whitespace property?
ED: That would be nice
DS: How about we say that XML space doesn't do what it did in SVG
1.1
ROC: So drop support for xml:space?
... how much content will break?
CL: None
ROC: Can we remove it from the test suite?
RESOLUTION: We drop xml:space from SVG 2 and remove the relating
tests from the SVG 1.1. test suite
ROC: Should warn authors that in SVG 1.1 that this is being
deprecated
<scribe> ACTION: Chris to Remove the tests from the SVG 1.1 tests
suite that relate to xml:space [recorded in
[25]http://www.w3.org/2011/03/03-svg-minutes.html#action04]
<trackbot> Created ACTION-3004 - Remove the tests from the SVG 1.1
tests suite that relate to xml:space [on Chris Lilley - due
2011-03-10].
<scribe> ACTION: JWatt to Draft a proposal to use CSS whitespace in
SVG 2 [recorded in
[26]http://www.w3.org/2011/03/03-svg-minutes.html#action05]
<trackbot> Created ACTION-3005 - Draft a proposal to use CSS
whitespace in SVG 2 [on Jonathan Watt - due 2011-03-10].
<pdengler> I haven't seen any activity here, are you still out to
dinner
<roc> we just got back --- from lunch
<heycam> Scribe: Cameron
<heycam> ScribeNick: heycam
Next F2F
<roc> I booked nine single-person kayaks, the tide is in the morning
so we need to be there at 9:30am :
[27]http://www.puhoirivercanoes.co.nz/puhoi_river_kayak_trips.htm
[27] http://www.puhoirivercanoes.co.nz/puhoi_river_kayak_trips.htm
<roc> I told them it might only be eight people in the end
[28]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Next_F2
F
[28] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Next_F2F
CM: jun mailed the list about meeting at the same time/place as
csswg in tokyo, in june
... I think we should meet then
AG: google offered meeting space just on the same dates as the csswg
meeting
... for the remaining days, canon or kddi can host
DS: maybe some csswg people can stay on for extra days to have
meetings with us, rather than eat into their meeting time
<scribe> ACTION: Chris to tell CSSWG that we want to meet them! In
Tokyo in June. [recorded in
[29]http://www.w3.org/2011/03/03-svg-minutes.html#action06]
<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
<scribe> ACTION: Anthony to coordinate with Fujisawa-san to organise
hosting for Tokyo SVG F2F [recorded in
[30]http://www.w3.org/2011/03/03-svg-minutes.html#action07]
<trackbot> Created ACTION-3007 - Coordinate with Fujisawa-san to
organise hosting for Tokyo SVG F2F [on Anthony Grasso - due
2011-03-11].
AG: how about the late year F2F?
CL: go to SVG Open, Mon-Wed, do Thurs-Fri SVG WG meeting
... then the week in between is free
... following week is TPAC
AG: I probably can't make the final Friday of the Tokyo F2F
DS: let's just make it Mon-Thurs on that week then
<scribe> ACTION: Chris to liaise with MS for the F2F meeting around
SVG Open [recorded in
[31]http://www.w3.org/2011/03/03-svg-minutes.html#action08]
<trackbot> Created ACTION-3008 - Liaise with MS for the F2F meeting
around SVG Open [on Chris Lilley - due 2011-03-11].
<pdengler> Could we consider the week of the 26th for the Face to
Face in ENgland?
<shepazu> pdengler: we are planning to have 2 days after SVG Open,
then the next 2 days at TPAC a week later
<shepazu> could microsoft host the F2F after SVG Open?
<shepazu> pdengler: the problem is, we really need to meet at TPAC
buffered-rendering
<jwatt>
[32]http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/User_controlled
_caching_of_rendering
[32] http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/User_controlled_caching_of_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: I'll give you a brief overview of the document as it stands
<birtles>
[33]http://dev.w3.org/SVG/modules/integration/SVGIntegration.html
[33] http://dev.w3.org/SVG/modules/integration/SVGIntegration.html
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
this is ISSUE-2071
ISSUE: SVG2 should block cross origin SVGUseElement property access
<trackbot> Created ISSUE-2407 - SVG2 should block cross origin
SVGUseElement property access ; please complete additional details
at [34]http://www.w3.org/Graphics/SVG/WG/track/issues/2407/edit .
[34] http://www.w3.org/Graphics/SVG/WG/track/issues/2407/edit
rechartering
DS: I've been working on the charter document
... addressed some comments from Cameron
<shepazu> [35]http://www.w3.org/Graphics/SVG/WG/charter/2010/
[35] http://www.w3.org/Graphics/SVG/WG/charter/2010/
<anthony_nz> Thank you Mozilla for hosting a productive meeting!
trackbot, end telcon
--
Cameron McCormack ≝ http://mcc.id.au/
Received on Friday, 4 March 2011 04:21:10 UTC