- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 24 Oct 2013 14:01:23 -0400
- To: www-style@w3.org
Scroll Snap Points
------------------
- RESOLVED: Accept work on Scroll Snap Points as an Editor's Draft
TPAC
----
- Plinss asked everyone to add discussion items to the wiki
- Concern was again expressed that there was no answer on if there was
a room for the group to meet in on Sunday. plh said he'd look
into it.
- Later in the meeting, plh confirmed that there was a room set aside
for the Sunday meeting.
Daylight Savings Reminder
-------------------------
- Everyone was reminded that next week Europe will end daylight
savings time, but the US and therefore the telecon won't switch
until the week after.
Style Attributes
----------------
- Plinss requested that everyone remind their reps to vote positive.
Named Flows and Box Generation
------------------------------
- Stearns requested responses on the mailing list.
Outline-style: auto
-------------------
- The feedback from the web platform team will go through the normal
spec comment process.
Fragmentation and Fullscreen Elements
--------------------------------------
- Michou brought up his question on how fragments are handled in
fullscreen.
- The group felt that fragments should be ignored in fullscreen, but
that this should be addressed in fullscreen, not in fragments.
Therefore, Michou will provide his feedback on that mailing list.
setProperty and !important
--------------------------
- Discussion was deferred until zcorpan was available, perhaps at
TPAC.
device-pixel-ratio Zoom Behavior
------------------------------
- How device-pixel-ratio should interact with zooming was discussed
which included conversation about the different types of zoom.
- Proposals included having device-pixel-ratio only respond to one
type of zoom, creating a different property for different types
of zoom, and differentiating between zoom that changes the width
and zoom that doesn't.
- No resolution was reached and discussion will continue on the
mailing list and, if needed, at TPAC.
Writing Modes
-------------
RESOLVED: Publish another working draft of Writing Modes
=====FULL MINUTES BELOW======
Present:
Glenn Adams
Paul Adenot
Rossen Atanassov (Had to leave early)
David Baron
Bert Bos (Late)
John Daggett
Justin Erenkrantz
Elika Etemad
Simon Fraser
Sylvain Galineau
Daniel Glazman (Sometimes IRC only)
Koji Ishii
Dael Jackson
Peter Linss
Edward O'Connor
Matt Rakow
Florian Rivoal (Late)
Simon Sapin
Alan Stearns
Regrets:
Tab Atkins
Rebecca Hauck
Simon Pieters
Dirk Schulze
Lea Verou
ScribeNick: Dael
plinss: Any extra items?
Rossen: I have one
Rossen: I just wanted to make proposal for new module of snap points
Rossen_: I sent out an e-mail and I'm unfortunately far away
Rossen_: I was going to ask if we can discuss and I need to leave call
quickly.
plinss: Anything else?
Scroll Snap Points
------------------
<Rossen_> http://lists.w3.org/Archives/Public/www-style/2013Oct/0595.html
Rossen_: So this is a spec that we discussed a couple of times in
past.
Rossen_: Some of those discussions might have been in a hallway or off
topic.
Rossen_: They were basically were having to do with us proposing the
behavior of snap point.
Rossen_: We've been shipping it as part of our platform since IE10.
Rossen_: The two editors are MaRakow and Jacob...I don't remember the
last name.
<sgalineau> Jacob Rossi
Rossen_: They were working on other stuff and finally were able to
draft a spec.
<dbaron> http://dev.w3.org/csswg/css-snappoints/
Rossen_: Which we uploaded as an unofficial draft to above link.
Rossen_: As with any new proposal we wanted to get WG's buy-in.
Rossen_: I know that there was some discussion on www-style from Tab
Rossen_: This is something that we're just starting and want to start.
Rossen_: It is very rough and there are definitely things missing and
things to improve.
Rossen_: In order to get rolling we want to see how WG feels.
dbaron: I think it's great to have in draft; I would like to see more
of...I'd like to see additional stuff.
dbaron: In particular, along lines of what Roc proposed
<sgalineau> +1 to snap to elements
<sgalineau> or element edges
* glazou is ok for an ED pending other members are ok, IP-wise ;
question : in scope for next charter ?
dbaron: Having to specify manually in separate property is hard.
dbaron: Current it requires authors to specify edges when they're
often created by element to point out edges.
dbaron: It's great to see this draft, but I don't think we're set on
the details of that proposal.
dbaron: I'd like that addressed in draft
<sgalineau> +1 to new draft + dbaron/roc's feedback
<fantasai> +1 to dbaron's proposal
Rossen_: Would you like us to start with that as an issue?
fantasai: I'd like Roc's proposal before we do a first public working
draft.
<glazou> plinss, in scope for next charter?
Rossen_: We just have this as a unofficial draft, we're sorry about
originally putting in as and ED
Rossen_: Once we're okayed to start as ED, we can work on all these
issues before we do first public
fantasai: I don't think this needs to be an issue, just put in the
information.
Rossen_: I guess my question was unclear.
Rossen_: Is this issue something we should try and put in the
unofficial draft, or should we put in before it's ready for
first public?
<sgalineau> thinks this can just be an issue in the ED
fantasai: I don't think it matters, that's just the next step.
dbaron: I don't think it matters either.
Rossen_: I think we can work on that. No problem.
plinss: Any objections to accepting it as ED?
RESOLVED: Accept work on Scroll Snap Points as an Editor's Draft
Rossen_: Thank you everyone, now I have to jump off
<glazou> please, ask about charter scope
plinss: Snap points should be in the next charter
<glazou> thanks
TPAC
----
plinss: We need more items on wiki
plinss: So far we haven't heard about meeting at TPAC on Sunday.
plinss: If we think folks are attending and available on sunday, we'll
still try and find meeting space.
jdaggett: Can we figure out from Adobe someone to set up a meeting
room and not use W3C?
jdaggett: Seems like someone has thrown this over the wall
plinss: We've been trying, but TPAC needs to set up a space
plinss: I can ping Adobe
jdaggett: It seems like we need to corner someone
jdaggett: We're trying to get a Sunday space, Adobe has been able to
get a space on Saturday. Let's figure out their magic.
Sylvaing: I don't think it was just Adobe, I think tancent helped.
plh: We also have to deal with the hotel. It might be too late at this
point, but it's worth a try.
plh: I know ?? is super busy and might not be able to help.
jdaggett: The request was 2 or 3 months ago; never answered.
plinss: They just said they'd see what they can do.
plh: I'll try and find out more.
jdaggett: This is frustrating because people are spending money and
time and AC meeting overlaps with us. I'm just a bit upset.
plh: I understand. I apologize. I'll get as much info as possible in
the next 24 hours.
plh: If not, we might need another way to meet.
jdaggett: What I find weird is we always meet Sunday and always have
to wrangle that room.
plh: To be honest, I was talking with Jeff and he said everyone in the
WG thought three days was too long
plh: I'll look into the matter.
fantasai: Wait, who said 3 days was too long?
plh: That was old feedback.
dbaron: After last year glazou said he wouldn't meet Sunday, but
he's not coming.
<glazou> right
plinss: I think that was from having so many things back to back, but
he was the only one.
plinss: That wasn't a group decision.
<glazou> correct
<plh> http://www.w3.org/2013/11/TPAC/#GroupSchedule
plh: I see on schedule it's there, that we want to meet on Sunday.
plh: So I'm going to check.
plinss: Ok,
plinss: Thank you.
Daylight Savings Reminder
-------------------------
plinss: Another reminder, the daylight savings time change happens
next week.
plinss: Be careful about when to call in
dbaron: In particular, next week call is an hour earlier for Europeans
Style Attributes
----------------
plinss: People, remind your reps to vote positive on that.
Named Flows and Box Generation
------------------------------
stearns: I'd like to encourage people to respond on the mailing list
so we can discuss as much as possible before TPAC.
stearns: I saw dbaron responded, thanks
stearns: Anyone want to talk now?
plinss: Anyone?
Outline-style: auto
-------------------
plinss: Anyone that can talk about this?
plinss: We got feedback from web platform folks?
dbaron: I responded on the mailing list; they understood my
explanation better than the spec.
dbaron: I don't see what's different about them, though.
plinss: Anything else we can do here?
plinss: Or wait for feedback from them?
dbaron: I don't...It was just one e-mail.
dbaron: I think it can be normal issue process for spec
Fragmentation and fullscreen Elements
--------------------------------------
stearns: Is michou on the call?
michou: I'm here.
michou: The main question is, right now the fullscreen spec that's
being offered
michou: Describes how things should be displayed when there is full
screen.
michou: However, there is no mention about how things that are
fragmented should behave in fullscreen.
michou: My question is, first, if this should be specified in the
spec, and which spec should it be?
michou: More general question is when there are these interactions
between specs, how is it handled, not just in this work.
michou: Which should take care of including the behavior?
* sgalineau is it just fragmented content of even just the interaction
of overflowing content with fullscreen?
<dbaron> I think it might be useful to include at least some of the
editors of fullscreen in a discussion about fullscreen.
<sgalineau> if I make an overflow:scroll element fullscreen and it
doesn't fit, what happens?
fantasai: The spec takes care of 2 aspects of things.
fantasai: New models should define fragments on their own.
fantasai: This should describe different classes of layout and sizing
constraints across pages.
fantasai: fullscreen might be different.
fantasai: If you're printing fullscreen, you should just print that
part, not the full document.
fantasai: This fullscreen doc is up front, so your intention in
there, not the rest.
fantasai: Makes sense you only print that, that's one possibility
michou: That was my conclusion too.
michou: When you're in fullscreen, you disregard the fragment.
michou: The question remains, where should that be?
fantasai: fullscreen spec.
michou: Okay
michou: stearns: anything else?
stearns: I think we should provide feedback in mailing list.
michou: I'll continue this on the fullscreen mailing list.
plinss: Anything else?
michou: Not from me.
setProperty and !important
--------------------------
plinss: There was discussion on the mailing list about this. Anyone to
talk about it?
dbaron: I can give in if other implementations are willing to change
plinss: Is there anyone familiar with the objection?
dbaron: The issue was discussed at Paris F2F
dbaron: The issue was how setProperty deals with existing declaration
for that property for various settings and the setProperty
having !important.
plinss: So the question is, is IE or Webkit willing to change the
behavior?
plinss: Anyone?
israelh: I'm curious, there was also in past discussion about if
!important needs to change for animations.
israelh: So is there a larger set that deals with !important that
needs to be addressed?
dbaron: I don't think they're related.
israelh: I think it's self contained.
Glenn: I think we should wait for Simon Peters (zcorpan)
plinss: So defer?
plinss: Maybe discuss at TPAC?
Lief: I think Simon Peters is coming to TPAC
Lief: Maybe not to CSS
fantasai: If he's there, I think we can pull him in
plinss: So defer?
device-pixel-ratio Zoom Behavior
------------------------------
plinss: This is an old thread getting life on the list.
plinss: It's about how it should behave when zoom is applied
plinss: Anyone want to talk about it?
smfr: We feel strongly in webkit it should only represent the
properties of hardware display.
smfr: It shouldn't change with zooming.
smfr: Other browsers want one to change, but in that case it should
have another name.
fantasai: That makes sense to me
dbaron: What is the use case? People are going to write media queries
with assumptions that won't hold.
smfr: One of our goals is to retain...to keep page zooming under user
control.
smfr: Not give authors too much control.
smfr: We don't want pages to rearrange when the user zooms.
hober: We also have when an author is trying to change things, when it
is small, the user zoom makes it smaller.
dbaron: There's a half dozen was for authors to do this
dbaron: This doesn't seem like the thing people will use to rearrange
content.
dbaron: They will use for low-level quality issues.
<Bert> I think there are at least three kinds of zooming: the
magnifier metaphor (doesn't cause any re-layout, or it defeats
the purpose); set medium font size (causes new layout);
simulate bigger/smaller pixels (probably does new layout?)
hober: That sounds like an argument for making it constant
dbaron: We're only talking about desktop, not mobile.
smfr: I think our position holds in that case. When we introduced
retina, the reason was people could provide high resolution
assets on those devices.
dbaron: Problem is it's a general tool and people will use for other
things.
dbaron: I'm concerned because everyone else seemed to like the other
direction and they're not on phone call.
MaRakow: In IE what we're doing is searching ratio is setting. When
users are doing higher res, we want to allow that, but we
want to mask anything in zoom with websites.
dbaron: Pinch zoom doesn't effect this.
dbaron: It's a little funny to define.
florian: When it comes to desktop zoom, the viewport changes etc. so
this argument doesn't apply.
smfr: In safari there's 3 zooms, including text size, make pixels
bigger
smfr: And apply a transform in retina view, when you use 2 fingers on
the track pad.
florian: I was referring to classic.
florian: For this I wouldn't mind pixels changing.
dbaron: I think we're talking about changing it for zoom where width
is changing.
dbaron: If you ctl+ and you zoom in a 1000 pixels wide
dbaron: Then your width is 667 pixels.
dbaron: In those cases, where the width changes when you zoom is when
we change the device ratio.
florian: If zooming changes the width it changes, if it doesn't change
width it doesn't change ratio.
<SimonSapin> +1 florian
<SimonSapin> MQ 'width' times 'resolution' should be constant on a
given device, IMO
* fantasai would like to request WD for Writing Modes, given we can't
publish LC until after TPAC at the earliest
florian: Given the confusion and that authors can use other options to
change
florian: 'width' .... is not confusing. So why is device-pixel-ratio
doing a similar thing confusing? Some zooms alter view port,
some don't.
florian: If it changes the view port, it should change.
smfr: It should always reflect relationship between CSS picture rules.
smfr: That means every type of zoom should change.
florian: I can see an argument for that.
florian: Pinch zoom is asking "please don't change the page, I just
want to get closer".
florian: There's no expectation of change
* sgalineau doesn't like the idea of a *device* pixel ratio changing.
That makes little sense. Do the device* MQ properties
change?
* sgalineau wonders if we're talking about a csspixelratio property
plinss: I do want to see it at a higher resolution
plinss: I think there's a media query that will accept that
plinss: If I've zoomed to where one pixel is taking my screen, I want
it to change.
florian: That slows it down significantly.
plinss: I understand. I'm saying it can be addressed.
plinss: I can accept devicepixalratio doesn't change
plinss: I want something that does
sgalineau: My understanding is that it's a ratio between the two. When
one of them changes the ratio changes.
sgalineau: That's what i suggested on IRC
florian: I wonder if a CSS pixel ratio property that's distinct would
fix it.
hober: I think that's fine. It should be named to avoid confusion.
florian: They will most likely take the one that works in the case
they thought of, but break in another case.
MaRakow: I think we want a different property that separates device
pixels and CSS pixels
MaRakow: This is what I want for pinch and this is what I want for
persistant.
florian: To address the earlier point, I think users expect things
MaRakow: I think where we want authors to distinguish is where users
distinguish.
florian: That's not what pinch zoom is for
florian: If you have multi-res image and the browser switches, that's
fine, but it doesn't allow author to change query.
florian: That provides high end definition
florian: Having a media query that triggers from pinch zoom allows
authors to re-do layout arbitrarily.
florian: That's no good.
florian: Re-rendering is fine from rules,
florian: Arbitrary is not fine.
MaRakow: I can't think of many scenarios for temporary zoom,
MaRakow: One thing I can think of is temporary assets.
florian: And if we go through media query, arbitrary is what you get.
MaRakow: I agree. You wouldn't want it to stack with zoom, it would be
a separate multiplier.
florian: Media query...is fine to change in type of zooming that
changes viewport.
Bert: I guess florian said it, I agree the magnification is in the
browser.
Bert: It doesn't expect the substitution.
Bert: We don't have to specify in media queries,
Bert: This type of zoom is outside CSS.
hober: With all this interest in defining device-pixel-ratio
hober: We should add device-pixel-ratio to media queries 4.
hober: An actual definition would be nice.
hober: In the past people have opposed change, but this is a cow path
that needs to be addressed.
<dbaron> I agree we should pave the cow path at this point.
florian: How do you propose...these two things have different syntax
and you can pick?
hober: Personally, I'd drop resolution media query, but I'd lose.
hober: We need to describe that they do different things.
florian: I don't want to be diplomatic. Resolution was first, maybe we
should syntasize that one.
florian: That's a separate question.
* fantasai thinks florian needs to correct the above
florian: The behavior and the name should be described independently
fantasai: How many implementers do we have of device-pixel-ratio?
florian: It's in presto, webkit perhaps
<dbaron> +Gecko
florian: At the same time, all implementations we have are prefixed.
dbaron: I believe it's un-prefixed in Gecko.
plinss: I'm hearing agreement we should standardize
florian: By this you mean?
plinss: The name for one.
florian: If we have one thing with a prefix, we should standardize. If
not, I'm not sure we should if we're going to migrate
fantasai: What about a webkit implemention?
fantasai: Does WebKit implement 'resolution'?
smfr: I think Apple turns it off.
florian: I think it was also intentional to not that in media 3, we
tested for existence, but not behavior.
florian: It's possible many have it, but don't treat it the same.
florian: So maybe we should go pave the cowpath
plinss: Sounds like agreement to add it to media 4, but we're not sure
on how to do it.
florian: I'm not sure what to address because not everyone has same
syntax.
florian: I think several implementers accept a ratios as the value for
media query.
fantasai: I'm thinking both ways make sense
florian: It's also in syntax.
florian: We agree what syntax should be.
dbaron: This is widely used enough, it will end up being
webkit-device-pixel-ratio in all browsers if we fiddle too
much.
plinss: I think it's fine to add extra syntax and features, but not
break existing.
florian: I don't think anything has changed since we talked and
decided the other way.
florian: What do we do with resolutions?
florian: Do we link properties together?
plinss: That's fine if the behaviors are identical.
florian: I'd like to see if people are using resolution in the wild.
florian: If no one uses it, let's kill it.
dbaron: It has value from accepting multiple units.
florian: I'll add both it and its alias between too.
florian: I'll find a blog post that describes syntax.
plinss: Still a question about behavior under zoom.
plinss: Fairly strong opinions that it should change.
plinss: Does Webkit still oppose?
hober: Yes
plinss: Is that something you're willing to change?
hober: I think it would confuse authors if we change.
florian: If authors are swapping low and high res, it won't be awfully
confusing.
florian: If they break it, it's because they shouldn't be doing it.
plinss: We're running out of time. How to this move forward?
plinss: If we don't standardize behaviors, we can't standardize.
<astearns> I think we need to hear from PLH before the call ends
plinss: plh, you still on que?
plh: yes, but on another point.
* fantasai plinss, can we get a resolution to publish writing modes
WD, since LC is not possible before TPAC?
florian: I think using media queries here is wrong
florian: I'm not sure how to convince anyone that's unconvinced.
hober: You're forgetting border width
hober: Media query is a natural way to do half width border-width
plinss: Discuss this on the mailing and at TPAC?
TPAC
----
plh: I can confirm that you can have a room on Sunday.
* jdaggett yay!
* dauwhe excellent!
plh: Same number of attendees as on Monday/Tuesday?
<SteveZ> I will not be there on Sunday due to a conflict
* dbaron would guess that one or two people have travel plans that
preclude Sunday by this point.
plh: Confirmation just arrived yesterday, so sorry.
Writing Modes
-------------
fantasai: I don't think we can get to LC in time for TPAC, so can I
publish a WD? The last one was a year ago.
jdaggett: As long as as long as the Tr fallback issue is marked as an
issue.
RESOLVED: Publish another working draft of Writing Modes
plinss: Thanks everyone
[Meeting Ended]
Received on Thursday, 24 October 2013 18:01:52 UTC