W3C home > Mailing lists > Public > www-style@w3.org > September 2015

[CSSWG] Minutes Paris F2F 2015-08-27 Part II: FXTF Meeting Part II; glyph-orientation, writing-mode Values from SVG 1.1, getTransformToElement, Path Animation,Zoom Features for Media Queries

From: Dael Jackson <daelcss@gmail.com>
Date: Mon, 14 Sep 2015 13:59:00 -0400
Message-ID: <CADhPm3t+PxH+eCXcOxiX61J_Nx+jimkttsoViSCQNDSVOTKNDQ@mail.gmail.com>
To: www-style@w3.org
Cc: public-fx@w3.org
FXTF Meeting (part 2)
=====================

glyph-orientation
-----------------

  - RESOLVED: Drop glyph-orientation-vertical values 270 and 180.
              Drop glyph-orientation-horizontal entirely.
              Drop text-orientation: use-glyph-orientation value.
              Treat glyph-orientation 0, auto, and 90 as aliases
              of the corresponding values of text-orientation.

writing-mode Values from SVG 1.1
--------------------------------

  - Add RFC2119 optional wording to svg writing-modes keywords.

getTransformToElement
---------------------

  - The group felt this needs to be defined better.

Path Animation
--------------

  - It was agreed that Shapes level 2 should add motion path so that
      it's all defined in the same places.

Zoom Features for Media Queries
-------------------------------

  - KDDI presented a proposal for a zoom features property to be
      added to media queries.
  - It was thought that these use cases were best addressed by a
      JavaScript API rather than a CSS property.
  - The breakdown of the various types of zoom that may need to be
      supported was helpful and sparked renewed interest in creating
      a more generalized spec involving zoom.

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

  scribe: dael

FXTF Meeting (con't)
====================

glyph-orientation
-----------------

  heycam: There were two things in writing-modes.
  heycam: One was the values for compatible with SVG 1.1 for
          text-orientation. We've discussed this before but there
          had been holdouts on our side, but we now all agree that
          we don't need them. They're not compatibly implemented
          everywhere.
  heycam: I'd like to propose removing.

  fantasai: I think there's probably some implementation that needs
            some values to work. Last time we discussed maybe 0deg
            needed to work in glyph-orientation-vertical.
  fantasai: I think 270deg doesn't have use cases. If exact
            compatibility isn't an issue, we can treat
            glyph-orientation-vertical as an alias.
  krit: Since they're different properties, I'd prefer to deprecate
        them.
  fantasai: We shouldn't change in the new property. You can't
            support two things that control the same behavior
            without defining how they interact. How it's defined
            currently is text-orientation has a special keyword. I
            suggest we drop the keyword and have the three values
            that are used map as aliases to the text-orientation
            properties.
  fantasai: We did this with page break. The technical way we did
            this is we defined page-break-inside as a shorthand of
            break-inside. This would be the proper approach to
            aliasing for the implementations that need to support
            glyph-orientation. If no one needs it we could drop.
  heycam: I thought we might be there.
  krit: I'd rather the text-orientation. I was verifying that what
        the new property supports is things that make sense.
  <fantasai> Proposal would be that 'glyph-orientation-vertical:
             0deg' is shorthand for 'text-orientation: upright',
             'glyph-orientation-vertical: auto' is shorthand for
             'text-orientation: mixed', and 'glyph-orientation-
             vertical: 90deg' is shorthand for 'text-orientation:
             sideways-right'
  <fantasai> And glyph-orientation-vertical is not a real property,
             only a shorthand
  <fantasai> And the other values of glyph-orientation-vertical are
             dropped

  heycam: The day before we were talking about support for
          glyph-orientation-vertical itself. Do you think we can
          drop that whole property?
  krit: One moment.
  krit: It only has upright, sideways-right and sideways-left. So as
        an alternative to 0deg, 180 deg and 270deg.
  jdaggett: We've been talking about a proposal for sideways-lr and
            sideways-rl going into the writing of shorthand which
            would necessary to making sideways be sideways right.
  fantasai: I don't think that affects too much what we're doing
            here. It might effect the mapping of 90deg.

  jdaggett: Is anyone in the room talking about implementing this
            value? glyph-orientation?
  fantasai: I'm proposing we drop. If there is no implementations,
            if everyone will drop their existing implementation and
            not be able to read glyph-orientation then we can drop
            it from the spec and define that glyph-orientation-
            vertical isn't valid.
  krit: I'd rather if we add text-orientation support and you
        ignored glyph-orientation when it was present.
  fantasai: That's not a great interaction between properties. I'd
            rather we define the interaction as aliasing because that
            gets everything to work correctly. You implement it as a
            shorthand and glyph-orientation: 0, auto, and 90 are
            'upright', 'mixed' and 'sideways'. So it only needs
            text-orientation plus this shorthand.
  krit: It sounds complex. It's backwards-compatible and specify how
        it works with the new, but it seems a lot of work.
  fantasai: It's less work because no where in your code base is
            checking two properties. You only support glyph-
            orientation when you're doing the parsing stage because
            it will map directly into the text-orientation. It saves
            you data.
  krit: Maybe not in Firefox, but having a new structure for a
        shorthand property is a lot of work.
  Florian: It's not a lot. Engines support shorthands already.

  heycam: To get back to implementation. For webkit and blink, do
          you support glyph-orientation-vertical: 0 now?
  krit: Just for SVG.
  heycam: Do you plan to remove?
  krit: The problem with removal is we have content out there.
  fantasai: If you're going to remove it, we'll remove the mention
            from all spec. If you're not, we need to define it, and
            this is a better definition.
  jdaggett: Do we know there's content using this?
  krit: It was used, yes. Illustrator does.
  jdaggett: Illustrator is ancient.
  fantasai: But Illustrator is an implementation. If they want to be
            able to implement that we need to support it. If any SVG
            reader needs it we have to define how to handle it in
            the new world in a way they can read their old content.
            This solves their problem.
  fantasai: We try and avoid situations with two properties that
            control the same thing. But when that happens, in CSS
            the override mechanism is the cascade.
  fantasai: This mechanism lets us use the cascade and that's the
            same thing we've done in equivalent situations like
            page-break-inside/break-inside, where we've had legacy
            syntax we needed to map over. If we don't have to
            support 180 and 270, which have no equivalent in text-
            orientation, this is the best way.
  <jdaggett> um, if no user agent implements this value I think we
             should drop it
  <jdaggett> legacy relationships do exist but if there's not a lot
             of content that uses this
  <fantasai> jdaggett, the issue is non-Web content. We need to
             define how it works for those implementations, even if
             no browser ever needs to implement it

  Florian: We spent a bunch of time looking at mechanisms to handle
           aliasing and this was best.
  heycam: Okay, in the case that we're not as close to removing,
          this keyword is a smart way to do it.
  krit: I disagree shorthands are easier to handle. Illustrator is
        interested in the new text-orientation property.
  fantasai: Proposal is drop glyph-orientation vertical, drop 270
            and 180, drop glyph-orientation-horizontal entirely.
            Drop text-orientation use glyph-orientation value. Treat
            glyph-orientation 0, auto, and 90 as aliases of the
            corresponding values of text-orientation
  heycam: I agree with that concept.
  krit: I agree with the first points. You know my opinion on the
        last, but I'm not going to object.
  fantasai: If we're doing mapping, this is the way we should do it.

  RESOLVED: drop glyph-orientation vertical, drop 270 and 180, drop
            glyph-orientation-horizontal entirely. Drop
            text-orientation use glyph-orientation value. Treat
            glyph-orientation 0, auto, and 90 as aliases of the
            corresponding values of text-orientation

  <Florian> Here is a page on the csswg wiki exploring different
            aliasing mechanism: https://wiki.csswg.org/ideas/aliasing

writing-mode Values from SVG 1.1
--------------------------------

  heycam: I was initially opposed to including the old keywords as
          aliases but my objection wasn't particularly strong. I
          tried to e-mail Jonathan Kew, but I didn't get a reply.
  fantasai: I think the spec needs that table. I don't think we need
            to require that every implementation includes it. We
            need that mapping for those that support the values. I
            think IE does.
  heycam: Unless anybody remains objecting, that's fine.

  krit: So what elements would be supported for SVG?
  fantasai: You either support the values or you don't. If you don't
            support SVG you need to support those values.
  krit: You suggested there's an ability to write it to the UA
        Stylesheet.
  fantasai: If you only need to support the presentation attr syntax
            you can do that. If you need CSS values you'll end up
            parsing in all contexts.
  krit: Will that be required for all UA that support SVG?
  fantasai: That's up to SVG group.
  heycam: I would say yes. Given that IE has the old values and
          others do, we might as well have unconditional support.

  heycam: What does it say in the spec re: required?
  <fantasai> "Implementations that wish to support these values in
             the context of CSS must treat them as follows: "
  fantasai: I should qualify that for writing modes conformance it's
            optional and SVG can say it's required.
  Tav: I think it should be required for SVG.
  fantasai: It's required in CSS in general if you don't support SVG
            you might not need to, but most UA will.
  heycam: I'm fine with it.

  ed_paris: Do we need a resolution?
  heycam: If that's the current state, then I guess it's fine to
          leave as-is.
  <fantasai> ACTION fantasai add RFC2119 optional wording to svg
             writing-modes keywords
  <trackbot> Created ACTION-716

getTransformToElement
---------------------

  <heycam> http://dev.w3.org/fxtf/geometry/
  heycam: In the SVG WG we just removed some method that was under
          defined that was getTransformToElement. The intention
          was to give you a matrix that transforms between one
          element in a system to another. One undefined piece was
          what happens when you have two SVG fragments.
  heycam: If you're going to support anything like that it should be
          more general than SVG elements. We wanted to find out if
          that's something people wanted to see. It's not urgent,
          but to see if people were opposed.
  smfr: It would work across 3D transforms? There are problems
        computing matrices with flattened. I'd like to see points
        and rectangular between coordinate systems which I think is
        geometry.
  heycam: Converting points and things is usually what you'll want.

  shane: So this returns a matrix, is that right?
  heycam: The old does a matrix. It was a SVGMatrix and recently
          changed to the added DOMMatrix. What's the actual method
          that does the transform.
  smfr: Do you have a link?
  <zcorpan> https://drafts.csswg.org/cssom-view/#the-geometryutils-interface

  heycam: So that relates to take a point, interpolate and take it
          to a point in another one.
  zcorpan: I don't really remember.
  krit: If you have a transform you can apply it to a point. You
        can't take it from one point to another point in a different
        coordinate system.
  heycam: The main definition seems to be missing.
  heycam: The answer is probably that these methods will do what
          they need to or that's an obvious place to put something.

Path Animation
--------------

  Tav: One piece that's missing is path animation. I think there's a
       lot of interest in it. I'd like to see it be implemented
       somehow. If you can just use a string or not and how you do
       that, I think birtles might know more.
  birtles: I'm not sure how much more. We discussed the other day
           and more or less agree on the attr on a property so that
           we can animate CSS transitions and animations. The part
           we need is the syntax for that. Having looked at what we
           have in motion path that could be more consistent to wrap
           up the SVG path function and allow using the shape
           functions.
  birtles: We haven't quite resolved it. We also talked about making
           it easier to interpolate. I wanted to try and solve that
           problem, but I want to adjust to the same thing SVG does.
           I think that's the state at the moment. I'm not sure
           there's anything to discuss.

  heycam: It got on the agenda to discuss the syntax issues. It's in
          the motion path animation and it's clear we should do that.
          Not sure who would be driving this.
  TabAtkins: Do we have a spec for the SVG stuff as properties?
  heycam: In the SVG 2 spec, yeah.
  TabAtkins: So put it there. It's a paragraph for the simplest form.
             I nominate heycam to write it.
  heycam: Okay.
  heycam: We'll discuss further in SVG.

  krit: We have CSS shapes split to different specs. Level 1 had
        circle, ellipse and polygon. Motion path has the path. Can
        we combine so future spec would reference this one?
  heycam: You want to move all the shape definitions into a single
          spec?
  krit: I'm asking if that would make sense.
  Tav: Where?
  TabAtkins: Shapes.
  astearns: I have an issue in Shapes level 2 to add path.
  astearns: We can add it there.
  krit: Sure, that would work for me.
  krit: I want to have it in one spec, I don't care where.

  Tav: Animation between path and shapes is non-trivial. I don't
       want to create something very complicated.
  heycam: I think that's a separate decision as to if the new CSS
          shapes will be used in this.
  krit: The motion spec defines the start point of the motion of the
        shape.

Zoom Features for Media Queries
-------------------------------

  <tkonno> https://lists.w3.org/Archives/Public/www-style/2015Aug/0224.html
  <tkonno> http://rawgit.com/satakagi/mediaQueryZoom/master/index.html
  <tkonno> http://svg2.mbsrv.net/devinfo/devstd/css-mediaquery-zoom/20150825_zoom_media_features.pdf
  tkonno: Today for the presentation we have the proposal for media
          features for MQ. The two topics are the basic
          functionality and features.

  tkonno: First is overview of zoom media features. First the e-mail
          above has a draft spec. This is an overview.
  tkonno: I proposal a new feature to control the styles or content
          to zoom. We prepared this to confirm the concept. The goal
          of my presentation is to get approval to proceed to an ED.
  tkonno: The use cases, we are interested in the mapping using SVG.
          For mapping, the map is zoomed out and the user wants the
          overview. On the other hand when the map is zoomed in they
          want the details such as landmarks.
  tkonno: The generated map consists of the marker areas so if the
          content switched according to zoom the user can get the
          appropriate information. It is essential for mapping to
          switch the content radius according to zoom.
  tkonno: Also zoomable high resolution features. This diagram is
          zoomable. In this case the user the feels that low
          resolution is enough when zoomed out. Then the diagram is
          zoomed in and they want high resolution images. These use
          cases are realized by JS or other than web standard. We'd
          like to recognize this with web standards.
  tkonno: Assuming these use cases are good, how can we do them?
          min-zoom is the new feature. In this example, if the
          ZoomRatio is <2.0 the content would be displayed.

  tkonno: The details. I explained the overview, but it is unclear
          how can we define zoom.
  tkonno: We think zoom is in two types. One is UA zoom, which is
          page and pinch zoom.
  tkonno: The pinch zoom is controlled by the user pinch zoom
          gesture and it doesn't effect the viewport.
  tkonno: Second is webapps control. They control the scale of the
          contents. So ZoomRatio should be represented as these
          parameters [page 8 of slide show]
  tkonno: This formula indicates the relationship between the device
          size and the content size.

  tkonno: This chart [slide 9] corresponds to the previous formula.
          There are 6 types of zoom type. I'm not sure all are
          needed or should be prescribed. From the viewpoint of
          mapping we need to prescribe #3.
  tkonno: As for the other types of the document zoom, it depends on
          the use case. So we'd like to propose the document zoom
          feature. Imagine the use case, the web page has a map in
          an iframe. The user might zoom the map content, but the
          user might zoom all content. It can be realized by the CSS
          transform.
  tkonno: When the webpage is zoomed in using pinch zoom it's the
          transform. In the case of the map, that should be changed
          with the pinch zoom.
  <dbaron> the term "zoom" seems quite overloaded
  <dbaron> and I'm not sure what some of these numbers in the slide
           actually mean

  tkonno: As we look back, if you agree with us we'd like to proceed
          to ED. Thank you.

  Florian: I read the mail, sorry I didn't reply on the list. I
           think you did a through job of describing how zoom can
           interact. There's one thing. Can you put back on screen
           slide 9?
  Florian: Just to be clear, when you're talking about document
           scale this is when the iframe is being engaged by a
           document around it. All the zoom you're talking about
           here is pinch zoom or transforms. That's the major
           difficulty. Having a MQ on pinch zoom changes the game.
           Normally pinch zoom is magnifying glass and not an
           opportunity for re-layout.
  Florian: I don't think this is compatible with how browsers do
           zoom. It's also not clear this is user friendly. Your
           cases are places that it can be done for a user in a
           friendly way, but there are ways that can not be. Though
           the model makes sense, in your examples you had pinch
           zoom or transforms it makes me think this might not work.
  Florian: What we can use in MQ is custom MQ. That way the
           application is in control of what it's doing. If you have
           the +/- it wouldn't be browser supported, but browser
           assisted. This wouldn't natively interact with pinch
           zoom, but you can hook events into doing this. You get
           less help from the browser, but you get some. It would be
           interesting to hear from browser vendors.

  tkonno: It's different than people with implementation need.
  Florian: From the user's PoV there are many bad ways of doing this.
           If you do what you had with the map that's fine, but if
           you re-layout while you pinch that is a bad interaction.
  TabAtkins: We can expose some events, but doing it directly is
             weird interaction with the compositor.
  smfr: We agree. We have a policy of not exposing pinch zoom for
        that reason. I think the map examples are deceptive. You
        could end up devoting too many resources. The author would
        think you could load high resolution as you zoom in, but it
        would be for the whole page. In the map example the author
        needs more control than responding to a zoom MQ. I don't
        think this is something we would be interested in.
  dino: It would be difficult to spec what would be used. What
        labels would intersect etc. You can't do a staticDOM on a
        pinch zoom level. There would be a lot of code on every
        frame.
  Florian: Even though in the general case this doesn't work, but in
           some specialized cases you can have this. You can have a
           custom MQ with JS that could work.
  dino: It could be a case where it makes sense in a containment
        element that would never re-layout.
  Florian: For some simple examples it might work out.
  dino: You can think of it as another way to do it where instead of
        different resources you're swapping.

  tantek: Can you get the zoom level in JS?
  dino: Sometimes, depending on the browser.
  tantek: Well what the MQ would be relying on.
  Florian: In a mapping situation with just pinch, you don't
           intercept a touch event.
  tantek: That's not the question. In maps today they do take over
          all the mouse events and don't let the browser zoom. What
          I'm talking about is there a way for a web page to just
          query.
  iank: Some Google apps do this, but it's horrible.
  tantek: I'd argue that if you're interested in this we should do
          that first and before that a MQ is premature.

  MaRakow: This is, it seems you're trying to have a MQ that's the
           ratio of CSS pixels to screen pixels. I would echo the
           same concern that this isn't going to be 1:1 with real
           map scenarios in reality. Trying to do this as a MQ
           implies the switch would be immediate upon crossing that
           threshold. I think some browsers defer that activity to a
           later point.
  MaRakow: I think to emulate a native pinch zoom by increasing
           fidelity I think needs to be more sophisticated. I do
           think there might be a good case to detect your screen to
           local CSS pixel ratio. I can see that, though maybe not
           as a MQ.
  liam: There's also an interaction with a11y issues. When I zoom in
        on a map I do it because I can't see the details. If the
        details change I'm going to be frustrated. There's a
        difference between zooming in for details and for what's
        there.

  tantek: Talking about this in theory is pointless. The wide
          variety you could do is incredible. All the parallax stuff
          added to scroll, for example. We don't have a MQ for
          scrolling either. I want to keep pushing back and saying
          no this is premature. Let's start with a simple JS DOM API
          and see what people build and we can see if there's a
          pattern in what people build.
  <tantek> e.g. http://www.sbs.com.au/theboat/ (parallax example)

  dbaron: It also focuses most on the most global zoom. Many things
          want to be just this local document zooms and not say
          someone is in the middle of zooming your be app. Some
          browsers might use zoom to show it, not the webpage
          reacting to that.

  Florian: This is an interface that happened in old Opera where you
           have a zoom out preview of your content and MQ starts
           making things strange, that doesn't quite work.
  Florian: Being liam's reasons, I'm not even sure the API from
           tantek is right because even the magnifying glass is just
           to make things bigger. I'm reluctant to hijack things.
           There are good things to do here, but I'm hesitant to
           have the problems.

  liam: There is an analogy to open type fonts. They can remove
        detail when the font is rendered small. There's precedent
        for this kind of behavior. But you don't change E to W as
        you zoom, but you can change serif to be flat instead of
        curved. I could see merit in that for SVG, but the set of
        use cases is different. That's done partly for making
        rendering fast. Fetching a network resource would slow
        things down.
  tantek: Thats' what Google maps do.
  Rossen: This is almost like saying you shouldn't do xhr based on
          user interaction. It's overstating.
  tantek: Authors can do stupid thing, that's not a for or against.

  zcorpan: For the high resolution use case, there's srcset for the
           x descriptor. When the user zooms in the browser can load
           high resolution?
  Florian: And that works better than MQ. The trigger points for MQ
           are basic. The logic for SourceSet approach is left to
           the browser and it can be smart.
  zcorpan: So if you start zoom in and you load the high image,
           there's no reason to download the low resolution.
  Florian: And in MQ if you go up and down it reloads every time.

  ed_paris: It seems the group doesn't agree with publishing. Do we
            want to resolve?
  heycam: It sounds like starting with JS API to expose zoom levels
          and events when zoom level changes.
  Rossen: Yes. That is an old discussion we had in Shenzhen where
          there was a spec that was supposed to be written by
          various members of the group and this didn't go well.
  Rossen: I think this is something that comes up more and more. We
          better get this spec done and document the different zoom
          types and then expose some minimal OM hooks so that people
          who care can build.

  dino: One thing that put me off it is any time the topic was
        brought up the response was we agree and you should do it
        our way. So maybe we should agree that we should come up
        with a new way.
  Rossen: I think there's a strong signal that we need something.
  Florian: In terms of exploring the different types, today's
           proposal does a good job of looking at the different
           types of zoom and how they interact.

  tantek: Rossen I'm not seeing the strong signal that you are.
  tantek: Which is why I'm advocating for the JS API for people to
          experiment and develop use cases.
  <tantek> also, zoom property?
  <tantek> are you (Rossen) going to drop that?
  Rossen: JS API is fine, I wasn't suggesting anything.
  dbaron: What Rossen is saying is before we have the API we should
          have a list of what the different types of zoom are and we
          don't have it.
  Rossen: In our implementation we've been trying to reduce the
          crazy things we were trying to do before.
  Rossen: I proposed a spec in the NY F2F on the zoom property.
  smfr: I was waiting on you for sites that do that.
  shane: I've collected data.
  Rossen: There were very few sites using zoom. There was one site
          trying to use zoom for some really weird reason and
          getting lucky, but as soon as you throw in different API
          and other user settings, it was a mess.

  birtles: Before we get on the zoom property, can we tie up the
           previous conversation?
  birtles: What is lacking in the current analysis of the zoom types?
  dbaron: In that document? I couldn't understand the types so I
          couldn't map.
  birtles: So we need more data?
  tantek: Is that document in IRC?
  several: yes

  birtles: I wasn't sure what use cases are lacking? The property
           isn't abstract, it is for maps they want to use it for.
  dbaron: I think a lot of people are saying this is not a good way
          to do maps.
  birtles: I'd be curious for a way ahead. KDDI was looking at
           pictures with media attr and I think that's where MQ
           entered the equation. I think it's clear that MQ in the
           general case isn't for this. I think high resolution
           photography use case isn't clear. You have low and high
           resolution and want to break up the tiles so just source
           doesn't address that.
  hober: Once you start talking tiles it's custom.
  tantek: Tiling is the abstraction that covers maps and these
          photos.
  birtles: They had some use cases covering this type of feature. I
           think it's clear that MQ isn't the way forward. There's
           more forward and for the tiles which is the way forward.
  ed_paris: Do we need a formal conclusion?
  ed_paris: I think that was the last FX topic?

  <break=15min(ish)>

<fantasai> ACTION fantasai to add note about baseline-table property
<trackbot> Created ACTION-717
Received on Monday, 14 September 2015 17:59:58 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:33 UTC