W3C home > Mailing lists > Public > www-style@w3.org > June 2014

[CSSWG] Minutes Seoul F2F 2014-05-20 Part II: Flexbox, CSSOM and CSSOM View

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 11 Jun 2014 09:02:23 -0400
Message-ID: <CADhPm3tc0ZS6hQm7QkQF8s2E08hmrdC6Ltfy6qmYW85d3rAdow@mail.gmail.com>
To: www-style@w3.org
Flexbox
-------

  - The unclear language in CSS2.1 for handling static positioning
       was discussed with the leaning to further clarify relevant
       details in the Flexbox spec.
  - fantasai and TabAtkins will get usage data and draft a concrete
       proposal on how to make flex-basis: auto less confusing,
potentially with a re-name.
  - RESOLVED: Publish Flex CR with the CR version of flex
       distribution algorithm.
  - Flexbox also needs more tests before it can go to PR.

CSSOM and CSSOM View
--------------------

  - Serialization and loading style sheets were the two main pieces
       of CSSOM that were considered broken and a few potential
       solutions to each were offered.
  - For CSSOM View cases where the viewport is smaller than the
       canvas was the first issue with different browsers handling
       the case differently.  Zcorpan will write out a proposal.
  - The GeometryUtils API was mentioned with zcorpan planning to
       look at the version Firefox shipped and work from there.
  - Sub-pixel position raised a lot of concerns and some
       implementors shared difficulties they've faced in trying to
       implement it.

==== FULL MINUTES BELOW ======

  Full Agenda: http://wiki.csswg.org/planning/seoul-2014#agenda
  Scribe: dael

Flexbox
-------

  plinss: Let's resume. I see you're queuing up for CSSOM?
  plinss: So we want to wait for Chris? Okay.
  plinss: Selectors 4?
  TabAtkins: We were doing flex last night and couldn't finish
             Selectors
  plinss: We'll defer that to tomorrow
  plinss: Flexbox.

  <astearns> http://dev.w3.org/csswg/css-flexbox/
  fantasai: There was a handful of editorial issues and there was
            the 'flex-basis: auto' issue.
  TabAtkins: When we were editing last night we can across a few
             issues. We were talking about static position and 2.1
             is incoherent.
  TabAtkins: It only defines left, right and top. And left or right
             are ignored, depending on if you're LTR or RTL.
  TabAtkins: CSS2.1 talks about it if you're a box where only sides.
  fantasai: This is editorial, but we can't rewrite without assuming
            that static position is being redefined.
  fantasai: I wanted to mention it as an issue. As far as normative,
            the old and new wording are equivalent in terms or
            results, it's just a difference of conceptualization.

  fantasai: If there's a strong option from anyone but Rossen let us
            know.
  dbaron: I might have an opinion.
  TabAtkins: Okay. What do we do about def of staticpos? Everyone thinks
             of it as a point.
  fantasai: I don't.
  TabAtkins: I learned it in web dev as a point. Is this errata or
             position?
  fantasai: I don't think we need to redo 2.1. It's awkward,
            but it's not wrong.
  fantasai: I don't know what we want to do, but we should do what
            we can in the CSS3 Positioning module.

  fantasai: dbaron any opinion?
  fantasai: On how to conceptualize style notation?
  dbaron: If you want to do centering it's easier to redefine as a
          point. You have to do it somehow, because right now if
          it's a box and than you choose an edge you already have to
          turn it into something else to do centering.

  plinss: I have the counter concern that going back to footnotes
          where we have a placeholder, why wouldn't that apply to
          statics and fixed and it could be a box and just usually 0
          size?
  TabAtkins: I can't be. Tables mess everything up.
  TabAtkins: I tried to say a place holder is 0 by 0 box where the
             abspos is and that just wasn't possible. It's
             inconsistent with flex and it didn't work for tables at
             the time.
  TabAtkins: Tables without content have a different staticpos than
             would have been given.
  fantasai: Staticpos in 2.1 is a set of four offsets, the fourth of
            which they forgot to define.

  dbaron: In theory you want that for vertical writing modes, but
          you want the definition that's appropriate for the writing
          mode.
  fantasai: You need both dimensions and we have bottom to top.
  dbaron: Except you use what we have for left or right, not the
          missing bottom.
  dbaron: Unless there's a mismatch between the abspos container and
          the containing block.

  TabAtkins: So we'll at least pursue the position. I'd like to make
             2.1 not wrong
  fantasai: It's not wrong; it just doesn't match how you think about it.
  dbaron: I don't think there's a need to change 2.1 but I don't
          know if the position spec is ready to be referenced in the
          place of 2.1.
  TabAtkins: It's not and that's my main problem.
  fantasai: I don't think we need to change 2.1, I think we just
            need to be clear about how we handle it. The wording in
            the Flexbox spec is unambiguous.

  Rossen: If position 3 is handled in grid, we'll likely do that in
          the future.
  fantasai: But for now if we're clear in flexbox that's good.

  TabAtkins: The gregwhitworth thing we did last night. More
             intrinsic ratios being confusing.

  TabAtkins: Yesterday we discussed flex-basis because
             flex-basis: auto is just deeply confusing
  TabAtkins: fantasai came up with a suggestion. Since flex-basis
             isn't used much and people are using the short hand, we
             may be able to change the keyword and keep flex: auto
             doing what it does.
  <fantasai> relevant email -
      http://lists.w3.org/Archives/Public/www-style/2014May/0192.html

  TabAtkins: So flex: auto would turn into flex-basis: change-as-needed
             which would be much less confusing.
  TabAtkins: Shorthand expansion would be weird but it's already
             weird.
  TabAtkins: I plan to add a use counter to see what the usage of
             flex-basis: auto is and if it's low we can change the
             keyword.
  fantasai: When we first had this spec auto matched max-content but
            with some issues from implementor feedback, it's no
            longer the same.
  fantasai: Right now there's no way to say explicitly "I want
            flex-basis of auto", which is a problem.

  TabAtkins: I think that's all the flexbox issues.
  dbaron: Do you have a proposal for the new name?
  TabAtkins: No.
  dbaron: Size comes to mind or use-size.
  fantasai: Match-size?
  dbaron: I'm trying to come up with something that matches width or
          height.
  TabAtkins: Main-size.
  TabAtkins: It means we use the main size.
  dbaron: Is that term author exposed?
  TabAtkins: It doesn't show up in any properties. It's extremely
             common in the spec but not used in syntax.
  dbaron: That seems reasonable to me.
  fantasai: So we can draft that up.

  <trackbot> Created ACTION-627 - Get usage data [on Tab Atkins Jr. -
             due 2014-05-27].
  <trackbot> Created ACTION-628 - Draft a concrete proposal [on
             Elika Etemad - due 2014-05-27].
  <trackbot> Created ACTION-629 - Draft a concrete proposal [on Tab
             Atkins Jr. - due 2014-05-27].

  plinss: Do other flexbox implementors have opinions on the change?
  Rossen: Should be fine.

  fantasai: So that's where we are. I want to go over aspect ratio.
  fantasai: The simplified version is if we have 100 x 100 image and
            set width: 50px and height: max-content
  fantasai: What's the size of the image?

  dbaron: Max-content shouldn't depend on specifying width or height.
  fantasai: It does.
  dbaron: It should depend on specified width or height inside, but
          not on the element itself.
  fantasai: That's not true on a paragraph. If I set width: 50px the
            max-content height will depend on that width.
  dbaron: That's what happened when you define max-content?
  dbaron: I don't like that definition.
  TabAtkins: It doesn't do anything useful otherwise.
  dbaron: It would be nice to pick something that didn't depend on
          width or height.

  Rossen: In the case of image I would expect it to be 50 x 100.
  TabAtkins: That's what spec says I think. That's not certain.
  TabAtkins: I don't think I like it but I'm confused.
  dbaron: I think if you want to try and define you'll end up with
          circular cases for some combinations for max and min
          width/height and content.
  TabAtkins: We're trying to avoid that with visibility hidden and
             min-width content. For something with an aspect ratio
             the height affects the width so it needs to feed in.

  fantasai: We have two options. One is to build smartness into auto.
            The other is to redefine min- and max-content to account for
            author spec constraints.
  dbaron: I'd rather the first one.
  fantasai: Okay.
  dbaron: I'd rather keep min/max-content like primitives.
  Rossen: Plus, we're close to get getting the first option.
  Rossen: To get unblocked I'd go with defining how auto works to
          the extent we can for edge cases.
  Rossen: There will always be more edge cases.
  fantasai: Okay. We'll work on that.

  fantasai: I think that's it for flex. And we're doing the CR
            version of the algorithm?
  fantasai: Did we discuss that?
  TabAtkins: If we didn't we should resolve.
  dbaron: CR being the older one.
  TabAtkins: The one based on the older one.
  fantasai: So let's remove that at the last moment before we publish
            Keep it until right before publishing.
  fantasai: So people can find inconsistencies which are indications
            that we screwed up somewhere.

  RESOLVED: Publish Flex CR with the CR version of flex distribution
            algorithm.

  TabAtkins: And we're going to say no to the proposal of Flex to PR
             since we know it isn't ready.
  plinss: What will it take?
  TabAtkins: More tests.
  plinss: Do we have a plan for getting there?
  plh: When you say more tests, do you have an idea of what's needed?
  TabAtkins: I haven't done a significant review, but I was told
             that there weren't enough.
  plh: It would be nice to have this, have somebody to tell us what
       needs to be tested.
  plh: Sometimes people come to us asking about what tests to write
       and I can tell them to write tests for this and this in flex.
  TabAtkins: Okay.

  plinss: So you're taking that on?
  TabAtkins: Yes.
  plinss: Do we have a test plan doc? It doesn't look like it.
  fantasai: If there aren't 1,000 tests, there aren't enough.
  dbaron: It looks like there's 400ish.
  TabAtkins: So we have half as many as we need.
  fantasai: Likely more like a fourth.
  dbaron: I think some are relatively complicated tests.
  dbaron: Which can pack a good bit in.

  dbaron: I'm curious about there being only one test for flex lines.
  astearns: When I last looked there were none for line.
  dbaron: It might be they're pointing to different sections.
  dbaron: We have a bunch pointing to baseline that are testing
          multiple lines.
  dbaron: Maybe not.
  dbaron: If I look at the directory of rough tests, there's a
          substantial number of commit messages for line, but none
          of them point to multi-line.
  TabAtkins: Okay.
  dbaron: A bunch are for baseline and there's a commit for rough
          tests for multi-line
  TabAtkins: I was coaching someone through writing a bunch of
             multi-line tests in Japan. Maybe they weren't reviewed
             or just not pointing right.
  plinss: Okay.

  plinss: That's it on flexbox?
  plinss: Chris isn't here, but should be, so let's start on CSSOM.

  dbaron: I just discovered that's a subdirectory that my import
          didn't contribute.
  dbaron: Wait a minute. That's because it no longer exists. I don't
          know what happened to it.

CSSOM and CSSOM View
--------------------

  zcorpan: State of CSSOM and CSSOM view
  zcorpan: The big items that need work in OM are serialization,
           which is kinda broken in general. It doesn't do the right
           thing for short hands.
  zcorpan: I think it doesn't support all of the things the CSS
           supports.
  astearns: I think there was a proposal to take the serialization
            rules for background and apply them generally.
  TabAtkins: I think we discussed that at previous F2F and I don't
             recall outcome.
  Rossen: We discussed it in terms of shapes. If you find that
          discussion it'll help.
  zcorpan: If someone finds that discussion, would they file a bug?

  dbaron: With the serialization there's interoperability between
          browsers with weird variations and we don't want to break
          existing interop. We've done that in the past.
  zcorpan: So we might have to make the spec property context
           sensitive.
  dbaron: It might be dependent.
  dbaron: It's not to a point where I would trust the spec to change
          a browser's behavior
  zcorpan: I wouldn't recommend that.
  zcorpan: If you have opinions about how it should work that would
           be helpful.
  dbaron: I have some general opinions. I think I've told you them
          before.
  zcorpan: File a bug, please, and write them down for me.
  <astearns> I believe the idea for serializing shorthands would be
             to use the rules I added for the <basic-shape>
             functions in
http://dev.w3.org/csswg/css-shapes/#basic-shape-serialization
             (paragraph 1, not paragraph 2)

  zcorpan: Anything more on serialization?
  glenn: Question on calc(), is there serialization rules there?
  TabAtkins: Nope. So, there is a question, as we define new
             functional forms, should that be in each spec or
             centralized into CSSOM.
  zcorpan: No opinion.
  glenn: I think we should make them closer or you have to rewrite
         CSSOM every time.
  dbaron: But CSSOM can define useful things for that spec to
          reference.
  glazou: As far as I'm concerned the biggest problem is gradient
          and transform for serialization.
  glazou: That is probably the highest for me.
  TabAtkins: And I defined it sometimes when I defined the spec.
  TabAtkins: I'd like a general rule for properties even if we have
             to violate that for legacy.
  TabAtkins: I want to know what to do about serialization.
  hober: Even if there's a world with pattern A and pattern B and we
         can reference that.
  <astearns> logged a bug on serializing shorthands:
             https://www.w3.org/Bugs/Public/show_bug.cgi?id=25822

  zcorpan: Style sheet loading is kinda broken. It doesn't say to
           parse the style sheet. It says load this and the
           style sheet appears.
  TabAtkins: It should all be hook-able.
  zcorpan: Likely nothing is preventing that, but I haven't had time
           to fix it.
  zcorpan: There's also cross-origin which might be some of it.
  TabAtkins: Do you have plans for a constructible style sheet?
  zcorpan: You can do that with insertRule. I have to write CSS
           syntax, but there are no constructors for each property.
  TabAtkins: Style sheet objects themselves. I have things we
             discussed internally to make style sheet handling
             easier, but I'll discuss that on the mailing list.
  glazou: document.createStylesheet or something?
  TabAtkins: Something to have more explicit sharing.
  zcorpan: Anything to add to style sheet loading?

  zcorpan: The open bug count is 31.
  zcorpan: From what I can tell the immediate implementation
           interest is css.escape() and CSSOM values
  zcorpan: TabAtkins had a proposal to make it better.
  TabAtkins: JS value objects. That won't be another year or two and
             a good API isn't implementable until we have that.
  zcorpan: A colleague was interested
  glazou: I am too. I'm not sure it's the right direction, but it's
          something I wanted to us. For CSS values outside of JS.

  zcorpan: Are people looking to implement other parts?
  zcorpan: CSS.escape() lets you take a string and have the value
           escape parts of a selector or a string that goes into
           content that you can use in insert group.
  dbaron: A lot of CSSOM is in DOM level 3 style and already
          implemented.

  plh: I see this was last published in last December. Have there
       been substantial updates that make this out of date?
  zcorpan: Not too much. I added the dashed property things.
  TabAtkins: For custom?
  <TabAtkins> el.style['background-image']
  zcorpan: No, not custom properties. I think it's a CSS style
           declaration? We investigated dropping it and the usage
           was too high.
  zcorpan: There were other minor changes, but not much has happened.
  zcorpan: I plan to do more on this after the summer.

  zcorpan: The CSSOM View spec.
  zcorpan: There's an open issue on how things should behave for
           scrolling.
  zcorpan: The spec has right now something no one wants to implement
  zcorpan: Microsoft or IE has logical behavior for some things, but
           not all.
  zcorpan: Firefox uses physical behavior for all the things.
  zcorpan: So it's more consistent and understandable and in line
           with how positioning works if you look at abspos.
  zcorpan: So I'm inclined to match Firefox in the spec.

  Rossen: What's the example?
  zcorpan: [white board]
  <dbaron> whiteboard drawing:
           http://lists.w3.org/Archives/Public/www-archive/2014May/att-0007/dsc06430-zcorpan-whiteboard.jpg
  zcorpan: Let's say this document is right to left and you have a
           case of a smaller viewport than canvas and you ask for...
  zcorpan: It to scroll left on the document element.
  zcorpan: Firefox approach is the top left point of the viewport is
           the origin.
  zcorpan: And right is the positive axis so greater values are on
           the right.
  zcorpan: If you scroll to the left you get negative values.
  zcorpan: IE has the same origin but the axis is in the other
           orientation.
  zcorpan: This is the same as how top and left work in CSS.
  zcorpan: It's also how the coordinates work in, I think, all
           browsers and also some properties. I don't remember
           exactly which ones.
  zcorpan: There's messages with the details in the mailing list.

  fantasai: If I was going to do this over I'd move the origin to
            the other side, but if that's inconsistent with how
            other coordinate systems work than that's not helpful.
  zcorpan: And it's not clear to me that the mouse coordinates can
           be changed to the IE model. That seems risky and might
           break websites.
  zcorpan: So I don't think we can switch to IE across the board.
  fantasai: Where is the IE origin?
  zcorpan: I think the same place.
  <fantasai> rossen thinks it's the top right corner.

  Rossen: Did you try with regular scroll? Viewports tend to be
          inconsistent.
  zcorpan: We need to spec both and it would be nice to be consistent

  zcorpan: My question is if Microsoft is willing to change or if
           Firefox is willing to change.
  dbaron: Did you test chrome or webkit?
  zcorpan: That's more insane. Chrome is close to Firefox, but
           there's a property that puts the origin on the canvas
           instead of the viewport.
  zcorpan: That's what I tried to do in the spec but it wasn't happy.

  fantasai: The problem with the origin being in the middle is
            you're just floating out there.
  dbaron: And it's nice to have your original scroll be scroll left
          of zero.
  fantasai: I feel sorry for anyone programming RTL with scrollers
            because they're all insane.
  zcorpan: I agree, but we need to pick.

  zcorpan: My preference is for Firefox because that it makes it
           easier to work with abspos.
  zcorpan: If you want to position and element where you click, it
           can set top and left to whatever coordinates instead of
           trying to transform from other origin.
  fantasai: I think mouse and scrolling should use same coordinates.
            If there's introp on mouse we should copy that.

  zcorpan: Should I move on or do people want to resolve or should I
           spec this behavior and see what happens?
  zcorpan: Opinions?
  TabAtkins: I have none.
  glazou: I think it's good to spec and ask for review.
  glazou: Anyone object to zcorpan specifying this?

  zcorpan: GeometryUtils is a new API that lets you get coordinates
           and dimensions from boxes after transformation so you can
           get...
  zcorpan: For instance, get a shape with these four points instead of
           getting the bounding box.
  zcorpan: How this works is just a big red box in the spec, but I
           think Firefox shipped an implementation.
  zcorpan: So now I can reverse engineer.
  fantasai: Who worked on this?
  TabAtkins: Roc did
  TabAtkins: And did a lot on the mailing list.
  zcorpan: The IDL is in the spec, just not the semantics.
  zcorpan: So that needs spec work. Any questions on this?
  zcorpan: Any questions?

  zcorpan: At some point I should revamp the overall model of how
           CSSOM View does it's thing because right now it's too
           hand-wavy.
  zcorpan: Part of the problem is the specs themselves are hand-wavy
           and there's no foundation to build on.
  zcorpan: It's not spec'ed how to make a render tree and how to
           make boxes from it, it's just described how the end
           result should be.
  TabAtkins: We need a render tree description and a description of
             how hit detection works.
  zcorpan: So it's an issue that needs to be fixed.

  zcorpan: Part of the model problem is the CSSOM specs are unclear
           about when things happen. When you resize the viewport,
           when do we fire the change.
  zcorpan: What's the order?
  zcorpan: It just says when it happens you do both. That needs to
           be better defined.
  zcorpan: So we can test and get to interoperability.
  zcorpan: Any more points on the model?

  zcorpan: So other implementation interests that I can think of is
           sub-pixel position which is basically double return values
  hober: Which we did five days ago.
  <hober> FYI, WebKit changed Element.offset*/client*/scroll* to
          return doubles last week in:
          http://trac.webkit.org/changeset/168868
  zcorpan: And Blink is working on implementation and Opera. IE does
           have it for something things and for some things if you
           opt-in.
  zcorpan: So there is some compat concerns around this. I think
           Firefox tried and had to revert because sites broke, but
           I'm not sure if that's still an issue. It's unclear.
  zcorpan: I guess we'll find out from Webkit and Blink.

  hober: I think Roc raised a case where it was banging strings
         together to make a class name and when it changed from 0 to
         0.0 the selector took on a very different unit.
  zcorpan: Was it 0.0 or 0.01?
  hober: Doesn't matter.
  <TabAtkins> ".foo" + size changing from yielding ".foo0"
             (valid selector) to ".foo0.0" (invalid).

  hober: If we had CSS-escape() years ago...
  dbaron: A lot of these APIs don't account for features on the web.
          How much is it worth evolving to account for some of these
          things? That's the part of between get.box.quads where it
          accounts for transforms.
  zcorpan: The argument where people are interested in implementing,
           they say that doing this would result in a better user
           experience for existing apps.
  zcorpan: They use offsetTop and scrollTop and you'd have a
           smoother scroll.
  zcorpan: We can always do new APIs that do transforms.

  dbaron: I think on this one we'll let you take compat risk first.
  <dbaron> (We take compat risk first plenty of the time!)
  Rossen: Our experience with this...there was a discussion and I'm
          not sure if it made it to the mailing list.
  Rossen: We tried that, enabling all of the CSSOM controls in
          floating points, and we had massive compat issues.
  Rossen: At the time, that was IE9, most of the content is relying
          on integer math and as soon as we produced floats we had
          massive breakage.
  Rossen: asp.net servers started choking on mouse events with form
          submissions. I don't remember the issue, but we had to
          turn off the mouse events floating point because of the
          server being unable to handle them.
  zcorpan: Do you have a list of APIs?
  Rossen: We support something for all the APIs if you turn them on.
          That's why they're not on by default. The only one that
          is on by default was the one shipped by Firefox.
          Everything else is optional.
  Rossen: A list of specific APIs that are breaking stuff, that we
          don't have
  Rossen: It would be easy to browse and observe breakage.

  zcorpan: So assuming we find it's not compatible for Webkit and
           Blink would you prefer opt-in like IE or a new property?
  zcorpan: Some people don't like opt-in since different scripts can
           use both and generally people have a distaste for
           document-wide switches.
  Rossen: Then you end up with mixed content where half is floats
          and half is integers.
  dbaron: But if you have one library that expects one thing and a
          different library looking for another, you don't want to
          have to rewrite a library. So I'd be happier with two
          properties.
  zcorpan: I agree. Would IE be okay with that direction?
  Rossen: I don't see why we'd be unhappy.
  Rossen: In fact most of the window 8 store apps are using it as on
          by default.
  plinss: But there's no need to standardize.
  zcorpan: Do you know if people are using it on the public web?
  Rossen: I don't know but I can find out.

  plinss: This ties into a later topic but I think that all these
          APIs are broken so I'm reluctant to add new ones. I'd
          rather a proper box model and put the good APIs on that.
  zcorpan: So you don't want a fix soon, you want to wait on the
           better APIs?
  plinss: I want both. I want the better APIs soon. In general I
          don't want to spend too much time fixing presentational
          APIs on the DOM, I want to get a proper API. I want to
          expose the box tree and have APIs that work on that.

  dbaron: One point of order, do we have something from 1pm to 2pm
          that has to go in that slot because if so we need to break.
  zcorpan: Should I continue after lunch? I'm almost done.

  zcorpan: The other thing I've seen interest in is smooth scrolling.
           That's a new thing and lets scripts opt into letting the
           user agent do a smooth transition when the script scrolls
           or you navigate to an item.
  glazou: It's to enable/disable smooth scrolling, or it's to spec
          how it will scroll?
  zcorpan: You enable a point that you're scrolling to. This is an
           opt-in to scroll to this point but smoothly.
  dbaron: Is the scroll behavior or something else?
  zcorpan: Two things. There's scroll behavior that lets you opt in
           and there's a dictionary you can spec when invoking
           scroll API.
  dbaron: I like the dictionary, I'm not sure about scroll behavior
          as a property.
  zcorpan: Can you elaborate in an e-mail?
  dbaron: Okay.

  zcorpan: And then there's GeometryUnits. I'm not sure if other
           browsers want to implement that immediately. That's all I
           have.

  glenn: Since the DOM 4 was moved to HTML and CSSOM is important to
         HTML 5, has anyone thought to move this to HTML since API
         is a big priority?
  plh: I don't think it's a good idea. CSSOM has been the hot potato
       and it needs to be done.
  hober: zcorpan is here and doing the work so let's do it here.
  zcorpan: I don't have an opinion.
  plh: I think this group is the right one. You guys know the
       complexities. I think the dependency plan is to say CSS isn't
       in REC, but lets face it, it was part of DOM 3 and there
       aren't any major details changing.
  plh: Th plan is to say it's not a REC and that's fine.
  zcorpan: Okay. Lunch?

  [break = lunch]
Received on Wednesday, 11 June 2014 13:02:51 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 June 2014 13:02:52 UTC