W3C home > Mailing lists > Public > www-style@w3.org > November 2013

[CSSWG] Minutes TPAC F2F 2013-11-10 Sun I: Agenda, GCPM, Canvas and Video and CSS Image, and Device Pixel Ratio

From: Dael Jackson <daelcss@gmail.com>
Date: Tue, 19 Nov 2013 20:57:18 -0500
Message-ID: <CADhPm3vUBDWVG7yC7q=Esxx9w983ZBX7ecvOjWFg=nsM=BQ5tA@mail.gmail.com>
To: www-style@w3.org
Agenda
------

  - The agenda for the meeting was discussed. Details are on the wiki:
         http://wiki.csswg.org/planning/tpac-2013

GCPM
----

  - RESOLVED: David Cramer (dauwhe) is the editor of GCPM

Canvas, Video, CSS Image
------------------------

  - Krit presented information on his desire to add a canvas function to
         CSS Image.
  - RESOLVED: The working group would like to see work on canvas for
         CSS4 image.

Device Pixel Ratio
------------------

  - The group discussed the ways various platforms handle the pieces of
         device pixel ratio.
  - The level of detail to display as zoom changes was an area of
         particular concern.
  - Hober and Matt Rakow were actioned to write a proposed resolution to
         resolve the differences.


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

Present:
  Rossen Atanassov
  David Baron
  Bert Bos
  Rik Cabanier
  Dave Cramer
  Elika Etemad
  Sylvain Galineau
  Israel Hilerio
  Dean Jackson
  Taichi Kawabata
  Philippe Le Hegaret
  Chris Lilley
  Peter Linss
  Cameron McCormack
  Simon Peters
  Simon Sapin
  Doug Schepers
  Dirk Schultze
  Alan Stearns
  Leif Arne Storset
  Lea Verou
  Kazutaka Yamamoto

Agenda: http://wiki.csswg.org/planning/tpac-2013#agenda

Agenda
------
  scribenick: ChrisL

  plinss: See wiki. We have some joint meetings also
  <dbaron> http://wiki.csswg.org/planning/tpac-2013
  plinss: There are some requests for slot movement due to people not
          here on Sunday.
  krit: When is SVG joint meeting?
  (Tuesday)
  plinss: TabAtkins should be calling in.
  krit: Can we discuss CSS image?
  fantasai: Yes, I'm here.
  dauwhe: Digital publishing related: not Monday.

  fantasai: We should wait for shapes until Simon and Leah get here, but
            today is ok.
  plinss: Text and Writing Modes will be on Tuesday morning.

GCPM
----

  dauwhe: This seemed unresolved on conference call. I've been writing
           test cases and would like someone to co-edit.
  plinss: Hakon has decided to work outside the group, we need to work
          inside the group for patent policy.
  plinss: dauwhe is willing to edit.

  Bert: Hakon wants the group to not do anything for some months,
  Bert: I think this is a good idea.
  Rossen_: which one, the one we decided to split?

  dino: There is a very easy solution to 'avoiding confusion'
  heycam: As long as its different names for different proposals, it's
          no problem.

  dauwhe_: So do we wait a few months or not? It should stay in the CSS
           fold.
  krit: What's your preference?
  dauwhe_: Press on. I'm interacting with him if he wants to continue
           contributing ideas.
  plinss: any objections?

  RESOLVED: David Cramer (dauwhe) is the editor of GCPM

  (discussion on spec naming and disambiguation)
  * sgalineau it could be GNU: GCPM is Not Unique
  ChrisL: good decision, start with last (split) editors draft.

  dauwhe_: I would like some cleanup time before publication. I noticed
           some holes while writing test suite.
  ChrisL: Are you looking for reviewers for tests?

  plinss: Are you familiar with the test format?
  dauwhe_: I'm learning.
  dauwhe_: I'm noticing lots of small differences even in property
           naming between implementations.
  plinss: Implementations are not done by members of the working groups
          so be aware of patent policy. Lean towards what can be
          implemented by others.

  dauwhe_: There is a larger question of how much we build on that spec
           and how much we build on regions.
  plinss: The more we can leverage from existing work, the better.

Canvas, Video, CSS Image
------------------------

  krit: (learns airplay)
  krit: (demo)

  krit: I would like to add a canvas function for a canvas2d graphics
        context to <image>,
  krit: Draw into and use it directly as a CSS image.
  krit: Many authors like this.

  ChrisL: Any downsides?
  krit: You need to reference a dom element directly to be selectable,
        canvas is created directly.
  dino: On the document element you ask for the context directly.
  ChrisL: Can it be treated as a separate single element dom tree?

  fantasai: There's a similar issue with a CSS element map that was in
            an earlier draft,
  fantasai: You could put things into the map that were not in the
            document tree.
  dino: Element function has security issues with access to pixels,
        spelling dictionary, etc. Canvas is clearer, page author drew
        into it.

  israelh: Can be a WebGL context?

  dbaron: I want to see a written proposal so I can get reactions from
          others at Mozilla.
  krit: That's fine; I wanted to get reactions from group before writing
        it down.

  heycam: Where does canvas size come from? What if you call the
          function multiple times with different sizes?
  dino: These are completely independent and can be displayed at any
        size.

  plinss: What's the intrinsic size?
  dino: I dont know, maybe 300x150?
  Rossen_: It should be the same as what canvas does.
  plh: Can you query the size? Normally you query the canvas element not
       the context.
  dino: That would be real handy.
  plh: It needs to be added to context and to WebGL as well

  <krit> http://adobe-webplatform.github.io/Demo-for-Food-Network-Cupcakes/
  * leaverou URL above doesn't work
  <astearns> http://adobe-webplatform.github.io/Demo-for-Food-Network-Cupcakes/src/#page/view-cover

  plh: Can take a video element and draw that into the canvas?
  dino: Yes.
  dino: The proposed WebGL extension with live update from video into
        canvas...
  dino: It's very complex, keeping audio and video in sync, loose audio
        sync is messing with video frames and then you need to resync.
  dino: So for v1 make it a static snapshot from the video.

  cabanier1: Canvas has no memory.
  cabanier1: Does the canvas have a lifetime?
  dino: The reference count.
  ChrisL: display: none vs visibility: hidden which keeps the canvas
          context.

  krit: The next step is a spec proposal since there is interest.

  RESOLVED: The working group would like to see work on canvas for CSS4
            image.

  Action: krit to write up canvas for css4 images
  <trackbot> Created ACTION-588 - Write up canvas for css4 images [on
             Dirk Schulze - due 2013-11-17].
  fantasai: ok

  krit: Video function...
  krit: We could think about a video background, adding an element mixes
        markup and style.
  dbaron: With video as a background image, what about the audio? Is
          there a mute button?
  heycam: Pause, etc?
  heycam: Because pause/play/etc. is on the DOM element itself.
  krit: No audio, just the video

Device Pixel Ratio
------------------

  (TabAtkins is not here. We look at our shoes.)

  dino: Apple seems to be in the minority here. It's not
        window.devicepixelratio
  dino: Hixie wants to add it to html and
  dino: Mozilla changes it based on full zooming

  dbaron: On desktop we have two types of xzoom, one changes only font
          size and the default one zooms all measurements and thus
          changes the device pixel ratio. So the width in CSS pixels is
          shrinking.
  Rossen_: We have the exact same behavior.

  dbaron: So this should be reflected in the media query.
  dbaron: Pinch zoom means having two viewports, logical viewport
          scrolls into a real viewport.
  dino: Authors want to know those values too.
  dbaron: For compatibility the media queries need to be logical
          viewport.

  dino: I intended a fixed value of device pixels:css pixels so it is
        always 1 or 2 on apple devices.
  dino: Doing live ratio is a different thing.

  SimonSapin: Is this accessible from javascript or mq?
  dino: Both, with the same value.
  Rossen_: So you account for dpi into dpr?
  dino: : No, it's always 2 or 1 regardless of zoom#.

  Rossen_: We persist with high dpi, same as with user zoom, (the user
           can change dpi),
  Rossen_: Anything to do with device adaptation,
  Rossen_: Like text size adjust.
  israelh: Static vs Dynamic

  dino: Hixie on whatwg list said he would like to expose these
        persistent properties as a new property but Robert said it
        should just be dpr.
  israelh: There's also a proposal to add a second api.
  dino: It's difficult to change now because it would break content.

  (missed)

  Bert: What is the value for print?
  dino: 1. Hmm. Not sure.
  ChrisL: So it's a retina yes/no value?
  dino: Yes.

  plinss: Gecko and IE show the actual ratio.
  dbaron: Yes, it's a float.

  dino: I would like to see something new that gives you all this info:
        actual display pixels, page (user) zoom, viewport within that.
  dino: You can't replace a lo-res with a hi-res image for example.
  ChrisL: Re-layout and replacement of assets are different.
  Rossen_: Currently for us it's just a transform, there's no impact on
           layout.
  plinss: If you have an image source that has multiple resolutions it
          should respond.

  heycam: What about mapping where you want new layers to come in during
          a gesture?
  dbaron: A mapping app is not using the browser zoom.

  dino: People add event listeners to detect pinch zoom and
  dino: Want UI to be a fixed size.
  sgalinea_: You can zoom a sub frame. IE10+ allows the author to say a
             sub-frame can be pinch-zoomed independently from the host
             page.
  dbaron: We can't do different levels of detail automatically as they
          zoom in.
  dbaron: Would like to expose API for pinch zoom to the Web platform.
  heycam: I proposed a way to do this in Tokyo, response to KDDI tiling
          but using media queries.
  heycam: That's hard if pinch to zoom is not exposed to media queries.

  Rossen_: We have two different types of zoom to address, one is static
           and persists across sessions and the other is dynamic.
  Rossen_: The original discussion was around the static one. So can we
           settle that one first?
  dino: I'd prefer what we come up with is a new solution with new names
        so old content does not break. If we do that it's better to
        design together.
  Rossen_: So deprecate dpr and make up two new things?

  israelh: Suppose you have a device that is 1.5 but user setting is
           1.25?
  ChrisL: Deprecating in favor of a richer solution is the only clear
          way to create interoperability.
  dino: And the new api has more functionality so it will get used.

  dbaron: Write a spec defining these terms.
  dino: hober will do it
  Rossen: I'll volunteer Matt Rakow.

  krit: Is it a part of media queries?
  Rossen_: It sounds like a new proposal.
  sylvain: Or the device adaptation document?
  SimonSapin: Are these all media queries?
  dino: It's also properties on window
  dino: and if media query values change it's good.
  plinss: The device adaptation module covers similar ground so we
          should coordinate.

  Action: hober and matt to write a proposed resolution to resolve the
          proposal about device resolution (using unambiguous terms)
  <trackbot> Created ACTION-589 - And matt to write a proposed
             resolution to resolve the proposal about device resolution
             (using unambiguous terms) [on Edward O'Connor - due
             2013-11-17].

  plinss: We have this speard over several documents.
  Rossen_: We could consolidate them all.

  israelh: Will this define the final overall zoom?
  Rossen_: Yes.
  plinss: It will define which is exposed to media quiries, when they
          update, and so on.
  Rossen_: And we need a backwards compatible way to map old stuff to
           new properties.
  dbaron: We're more likely to be willing to not-change-with-zoom than
          to use only 1.0 and 2.0.

[Break]
Received on Wednesday, 20 November 2013 01:57:53 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 20 November 2013 01:57:55 UTC