- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 19 Nov 2013 20:57:18 -0500
- 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