- From: Dael Jackson <daelcss@gmail.com>
- Date: Fri, 2 Jan 2015 09:51:27 -0500
- To: www-style@w3.org
Zoom Effects
------------
- maRakow presented his research and thoughts on splitting the
layout and visual viewports. His slides are available here:
http://1drv.ms/1xAK9Hd
- There was support for his thoughts about clarifying the meaning
of "viewport" when a spec isn't specific, especially for the
older specs. maRakow will make a list of references that need
clarifying and send it to the mailing list.
- Though people didn't want to define zoom behavior in such a way
that it limits smart design, they were very much in favor of
giving authors more controls to create those smart designs.
- Discussion about all these issues will continue on the mailing
list.
Flexbox
-------
- RESOLVED: alignment in Flexbox should depend on the value of
flex-wrap (wrap or nowrap), not the number of lines that result.
- Most of the other issues will be addressed by the authors
:role()
-------
- RESOLVED: add :role() to selectors
==== FULL MINUTES BELOW ======
Present:
Rossen Atanassov
Tab Atkins
David Baron
Bert Bos
Richard Byers
Dave Cramer
John Daggett (on phone)
Elika Etemad
Simon Fraser
Sylvain Galineau (on phone)
Daniel Glazman
Dael Jackson
Dean Jackson
Brian Kardell
Brad Kemper
Ian Kilpatrick
Peter Linss
Michael Miller
Shinyu Murakami
Edward O'Connor
Simon Pieters
Matt Rakow
Florian Rivoal
Andrey Rybka
Hiroshi Sakakibara
Simon Sapin
Dirk Schulze
Alan Stearns
Shane Stephens
Bobby Tung
Alan Turransky
Lea Verou
Ian Vollick
Kazutaka Yamamoto
Steve Zilles
Scribe: dael
glazou: Welcome to the second day of the CSS meeting.
glazou: We have a few things for today. The wiki says animation
behavior, but that's this afternoon. We have flexbox
issues, layout.
glazou: There's the AC meeting from 11-3, I will be there, plinss
will chair until 2. Bert will chair for the 2-3 hour,
thank you, Bert.
glazou: So we have flexbox issues?
Viewports and Zoom
==================
[maRakow's presentation available here: http://1drv.ms/1xAK9Hd]
maRakow: I want to talk about what's missing from specs as they
stand.
maRakow: The behaviors are for zooming in various ways and how we
think about the viewport in various situations.
maRakow: There's a couple current descriptions that we have. In
CSS OM we have page and pinch zoom.
maRakow: And in device adaptation the actual viewport is the
viewport used.
maRakow: First thing is why don't we have one zoom type. I'll go
through this fast to ensure we're on the same page.
maRakow: If we have a page content and we want to zoom there's two
ways. Layout zoom where we increase the size of the
content and everything re-wraps within the viewport.
maRakow: We do this for consistent zooms. This is something the
user doesn't have negative issues of zoom in.
maRakow: The intention of the second type is less about re-flowing
the content and more about keeping it consistent.
maRakow: If it's more of a temporary zoom you may just want a
piece of content.
maRakow: In this situation we call the area you can see as the
visual viewport which is distinct from layout viewport.
maRakow: This isn't reflected in spec text. They're talking about
initial viewport and that's important to the layout, but
there's no text about the visual viewport.
maRakow: One reason it's important is pinched zoom and fixed
elements. Fixed is description as attached to a single
viewport
maRakow: Do you attach fixed to visual, layout, both?
maRakow: [shows an example on the screen]
<MaRakow> https://www.flickr.com/photos/34654941@N02/8560297430/in/photolist-8MXZUM-2nF5aq-baAvmM-fTMsFJ-e3rLc1-hVcTTe-ncLVr5-egjd34-mJuvoW-dDwovw-4aeSwh-6mC7FC-48nagT-bRgbVB-azj7AV-e1Ci8t-9bLLEJ-69489U-dk6EgQ-bXqvdN/lightbox/
maRakow: The two top fixed elements are meant to travel with you
on the page. Side navigation is supposed to align nicely
with the right content. That's a problem where fixed are
immune to scrolling, but when the document only expects
one direction of scroll they align to one side. When you
zoom, it starts to overlap the content.
maRakow: When the non-fixed content is zoomed it will overlap.
maRakow: [shows and example on Gizmodo] On this page there's a
side navigation aligned on the left side.
<MaRakow> http://gizmodo.com/
maRakow: What we do instead is fix to the layout viewport so it
stays to the side when you pinch zoom because the layout
viewport is stationary.
maRakow: If you attach instead to the visual, the content starts
to crossover.
maRakow: There's a couple way you can do this.
maRakow: Other scenarios are bars at the top and bottom, content
scrolling on left/right side of content (ie ads) and also
full page overlays.
maRakow: If you pinch zoom and attached to upper left corner, it's
hard to pinch zoom in.
maRakow: A page we use a lot is Atlantis World Fair.
<MaRakow> http://www.lostworldsfairs.com/atlantis/
maRakow: It's an example of fixed content that expects to align
with non-fixed content.
maRakow: Chrome has been doing a lot of work on this. It's similar
to what we're doing, they keep content aligned left/right
with fixed and not fixed.
maRakow: This is a sort of thing we'd like to see described in
some specs in terms of how the viewports interact, how do
the types of zoom interact, and defining the types of
zoom.
maRakow: There's a lot of words that get thrown around. base-zoom,
layout-zoom, and base-zoom are used interchangeably for
things that change inside initial containing.
maRakow: There's also visual-zoom and pinch-zoom. The ones we
favor are base and visual zoom since the terms often
don't describe all the ways the zoom can occur.
maRakow: My thoughts are we need to put through the existing spec
and spec what each spec is referring to as well as
getting good definitions.
dino: Do you expose any of these as APIs?
maRakow: In part that's where some of the proposals for the client
with client height are defined, They refer to a viewport.
Mostly we spec the property hanging off the document
layout with the client height viewport.
dino: So the user can know they're pinched in two times?
maRakow: We have a property that reveals that.
maRakow: We've talked about wanting a more explicit API.
dino: Do you ever expect the user or allow layout to happen as the
pinch zoom changes? Someone wants a legend on the map and
remain 1 to 1
maRakow: We don't. We have a few other things like touch keyboard
where when we resize we allow scrolling to the bottom
with the keyboard up. We have a positioning type where
you fix an item to the visual viewport, but that's the
only case.
dbaron: My assumption is every spec is referring to a layout
viewport because I think most were written before visual
viewport existed.
dbaron: I think...there was talk about the lack of
interoperability of all this that's interesting. I know of
one place where the video is online.
dbaron: I'm inclined to think that it ought not be necessary to go
through every last spec, though it would be nice as we
revise for clarity.
maRakow: I spent some time making a list and for the most part
it's swapping a word, but there were places where
clarifying text would be helpful. As I finish the list I
can send it to the ML.
<dino> http://lanyrd.com/profile/ppk/
<dino> http://www.youtube.com/watch?v=TF9ID1xwxno
<dino> Presentation on Mobile Viewports
<astearns> also:
http://www.smashingmagazine.com/2014/04/29/meet-mobile-web-handbook-new-smashing-book-peter-paul-koch/
<bradk> http://www.quirksmode.org/mobile/viewports2.html
smfr: When I was talking to Rossen he described the model where
when you're panning the layout the viewport isn't moving,
but when you hit the edge you start scrolling. Can you
clarify when the scroll events fire?
maRakow: We do fire scroll events. the model we have to interact
two viewports, one requirement is that if you pinch zoom
in, scroll down, pinch out and scroll up you should be in
the same place, so we need to make sure the viewports
travel together. They're a box within a box.
maRakow: So as you go down you drag both viewports with you.
maRakow: So if I pinch zoom in and pan up/down the fixed element
is aligned to the fixed element. When you hit the edge of
the layout port, that's when you start to drag the other
viewport.
maRakow: All the fixed elements are where you expect.
smfr: And if you zoom and scroll sideways...?
maRakow: It'll stay constant here since this page doesn't have
scroll available, but it should.
smfr: One issue I have is the position of fixed objects depends on
how you got to that state. We don't have that in iOS model.
maRakow: You mean like state pool?
smfr: You're dragging the layout viewport around. If you came back
to that same page, but arrive through different scrolling
action, you could end up in a different place.
dbaron: What does iOS model do different?
smfr: Can I project?
smfr: This is a page with four fixed elements, bars across the top
and bottom.
smfr: This is zoomed out. When I zoom in we keep fixed things
relative to the physical viewport so bars at 100% width
layout to a narrow width. If you follow that model and zoom
in enough fixed things crowd so we start pushing off screen
by interpolating between the two viewports so you scroll
around and see the edge of the fixed things.
smfr: That gives weird drifting behavior, but ameliorates the
problem where things get in your way. The layout of fixed
position doesn't have any difference.
BenPoulain: The iOS mobile website when you're targeting, it
wasn't defined for that.
krit: Would the elevator model work on yours?
smfr: No.
smfr: One thing I'd like to see is web authors express how fixed
should zoom. People layout fixed and leave the left or top
auto. I'd like them to be able to express that they always
want it at the top but it's okay to move it.
smfr: I've tried keying it off and it doesn't always work.
maRakow: We're trying to find compatible for desktop. We handle
fixed so at any point in pinch zoom you see everything
when you scroll. We tackled keeping content on screen at
all times with a new property which is device-fixed which
attaches to visual viewport.
maRakow: It's opt-in, but it seemed dangerous to do that by
default.
smfr: And that gives you different zooming? Doesn't it scale with
the page?
maRakow: Correct. If an author uses it they should already think
of it.
florian: Both behaviors make sense. Seems we need an author level
way of picking which they want.
dbaron: Some of this is more about adopting desktop to mobile, not
really about content made for smaller screens.
???: Not quite. I have a touch screen, but sometimes I want to
zoom. I'm not trying to pidgin-hole
dbaron: Keying off auto seems like the wrong thing to me.
maRakow: It works well with content aligned with non-fixed content.
If you leave the top/left on auto you don't have to do
resizing logic, it's always just aligned since it's
positioned as absolute.
maRakow: In the Gizmodo case, if you have a two column layout and
then position the fixed as top/bottom/left/right auto as
you resize you don't have to say change the left to make
it stay aligned.
dbaron: As the user resizes?
maRakow: Correct.
maRakow: Just resizing. As the margin is reduced by shrinking the
window, this pages will have a resize handler that
changes left if they're spec finding left. If it's auto
that'll auto be reposition along the content.
smfr: Auto changes the fixed element relative to the right place.
dbaron: Based on the assumption it's scrolled to the initial
scrolling positioning.
smfr: I think it's independent.
dbaron: It matches the original position.
smfr: It's kinda like using auto, you use it where it is. Anyway,
authors do this.
maRakow: I don't expect a conclusion today, I wanted to socialize
the problem. We can continue on the mailing list.
smfr: I'm hesitant to say...to spec the zooming viewport behavior
in such a way that all UAs need to conform and can't
innovate, but I'd like to see ways for authors to express
what they want and we can converge on behavior.
BenPoulain: And think about when you layout in the port.
maRakow: I think this is a good start.
glazou: Okay, so, nothing else on this?
glazou: Thank you very much.
Flexbox issues
==============
<fantasai> http://lists.w3.org/Archives/Public/www-style/2014Oct/0489.html
fantasai: I think we've got basically 3 issues.
fantasai: One of them, well 4.
fantasai: One was something TabAtkins and I have to work out and
might not be quite ready.
fantasai: Second was alignment difference should depend on if the
flexbox wraps, not the number of lines it happens to
wrap to.
fantasai: The spec says that if there is one line of flex content
then the align-content property is not used. If there's
more than one we use align-content to figure out how it
fits.
fantasai: The problem is in a flex container that has wrapping,
the alignment depends on number of lines. So if my
screen is wider than the author expects, they'll get
unexpected behavior.
fantasai: This should depend on if the flexbox is wrap-able, not
on if it has more than one line.
TabAtkins: The spec originally behaved like this and Alex
Mogilevski requested the change.
fantasai: I think the current behavior is more likely to give
unexpected behavior.
fantasai: Say I want to baseline-align items and center lines in
the box and you don't get that because it falls on one
line.
fantasai: So I think we should change it to just depend on
flex-wrap property. People responded it makes sense.
TabAtkins: He did respond and say it was fine.
fantasai: Other comments?
TabAtkins: I think we need a Rossen okay and we're fine.
plinss: So we're waiting for a call?
fantasai: He (dholbert) says he'll call in a minute.
[connecting phone antics]
TabAtkins: Did fantasai give you context?
dholbert: I was following in IRC.
TabAtkins: Comments? Yea/Nay?
dholbert: Yes. The align-content change makes sense to me.
fantasai: There's one more issue Rossen was going to talk about.
TabAtkins: He's not here.
fantasai: Okay. In that case maybe we can ask dholbert to call
back when he's here.
dholbert: Bye, talk to you soon.
dbaron: If there were enough to justify it dholbert could drive
here.
fantasai: I think we have 3 issues total, so I think TabAtkins and
I should work on one over the break, but I don't think
it's a WG issue. I think we'll all get confused.
fantasai: That's all for now, we can come back with rossen.
glazou: I suggest a 15 minute coffee break and that will allow
rossen to arrive.
[Break]
glazou: Let's restart
glazou: Since everyone is in the room and we have rossen, let's do
flexbox.
fantasai: He's waiting on feedback, so we only have one issue. The
total DoC will be 3 comments and we'll have to go
through the last one, maybe later.
rossen: If we get news, they should have had numbers by now. If I
get it we'll maybe take 15 minutes.
:role()
-------
TabAtkins: jcraig suggested a :role pseudo
hober: There's a few problems. One is the impl RA roles on the
elements. When you have multiple roles on one element, you
get all of them.
hober: For styling you may want to style that as a switch or a
checkbox. Right now that's difficult in CSS.
hober: There's also the case of wanting to simply style all the
buttons on the page.
hober: You want to be able to say :role(button) and be done.
TabAtkins: That's convincing. Is there anything outside that?
hober: We can always add more.
glazou: You mentioned implied role. So some won't need an assigned
role. We'll need to refer to HTML.
hober: In CSS we say the host language has that.
dbaron: It's :: or : ?
TabAtkins: It's a functional class. It should be an ident.
glazou: Can you have multiple roles?
hober: Syntactically you can,
hober: But only one is active.
glazou: So if you have multiple roles on one element, it's
whitespace broken?
dino: So if you do :role...
hober: You can do role=button and role="super button". Or we
separate in the list itself.
glazou: So the role attr is multiple but the :role() pseudo is only
one?
hober: Yeah.
dauwhe: dpub is working on adding things for role attr.
TabAtkins: Do you know if it will be consistent with this?
dauwhe: They haven't said. I'll raise that with them.
TabAtkins: So I guess that's simple. Objections to adding :role()
to selectors?
TabAtkins: So :role(button) would target anything that has a
button according to aria rules.
hober: It wouldn't match button role = checkbox or something crazy
dbaron: So people are okay with agreeing CSS won't do future
things to influence what the aria role is.
hober: It should be defined by pointing over there [to markup layer].
fantasai: We need to have another language that has CSS syntax for
that kind of stuff. Our stuff should be about styling.
fantasai: People keep asking us to put things in CSS that belong
in the DOM, because they want to use CSS selectors and
cascading to attach it to the tree.
TabAtkins: If someone would like to implement cascading attr
selectors in a browser *shrug*
dbaron: Having CSS do this side makes sense, but we can't do both.
hober: Should we have a note in the spec saying "you may be
confused"?
glazou: When we had selectors we didn't have a note. I'm not sure
we need a note.
hober: Okay.
glazou: So no objections?
RESOLVED: add :role() to selectors
glazou: Who is going to write the prose?
TabAtkins: I will.
Received on Friday, 2 January 2015 14:51:55 UTC