- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 25 May 2016 20:04:13 -0400
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
Scheduling
----------
- Microsoft has offered to host in January/February in Redmond,
Washington
- April/May will likely be in Tokyo or Kyoto area; people should
look for any conflicts in this time period.
Round Display
-------------
- Florian presented his proposal for a MQ to tell if a device is
rectangle, round, or unknown.
- Several people felt that unknown wasn't necessary; if a
device isn't round it can be assumed to be rectangular.
- RESOLVED: remove device-radius MQ, add MQ for shape: rect |
round with traditional boolean semantics
- There was a split in the group as to if viewport-fit should be
defined now or if the group should wait for implementation
experience with a middle ground proposed of giving some
guidance, but keeping it loose until there's implementations.
- RESOLVED: 1) Accept viewport-fit with three values: cover,
contain, auto.
2) Initial value is auto. UA can do anything it wants
as long as the content not designed for round
screens is easily 100% viewable by the reader.
3) Undefined what is outside the contained viewport
for 'contain'. UA can paint anything it wants,
chrome, black, canvas background, @page background,
photo of SF Bay Bridge, whatever.
- There were conflicting opinions on if polar origin was necessary
and how it should interact with other properties (if it exists).
- The interested parties discussed it over lunch and come up
with a solution to integrate the desired behavior with the
motion-path spec, making the motion path spec stronger in
the process. The proposal is:
- combine polar-distance and motion-offset -> offset-
distance
- polar-angle -> offset path
- polar-anchor and motion-origin -> offset anchor (initial
value is auto) which copies the percentages from
offset-origin so offset-position behaves like
background position.
- RESOLVED: Accept current proposal as outlined by fantasai (above)
- The motion path spec will need to be renamed since it's more
about path positioning than it is about motion.
- RESOLVED: jihye added as an editor of Motion Path spec.
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/san-francisco-2016#proposed-agenda-topics
Present:
Rossen Atanassov, Microsoft
Tab Atkins, Google
Takao Baba, Beyond Perspective Solutions
L. David Baron, Mozilla
Tantek Çelik, Mozilla
Dave Cramer, Hachette Livre
Elika Etemad, Invited Expert
Daniel Glazman, Disruptive Innovations (only IRC)
Daniel Holbert, Mozilla
Jihye Hong, LG Electronics (only IRC)
Joone Hur, Intel Corporation
Koji Ishii, Google
Brad Kemper, Invited Expert
Ian Kilpatrick, Google
Chris Lilley, W3C
Peter Linss, HPI
Myles Maxfield, Apple
Edward O'Connor, Apple
Simon Pieters, Opera
Florian Rivoal, Vivliostyle Inc.
Andrey Rybka, Bloomberg
Hiroshi Sakakibara, Beyond Perspective Solutions
Simon Sapin, Mozilla (only phone)
Jen Simmons, Mozilla
Geoffrey Sneddon, Invited Expert
Alan Stearns, Adobe
Shane Stephens, Google
Greg Whitworth, Microsoft
Regrets:
Dael Jackson, Invited Expert
Hyojin Song, LG Electronics
Lea Verou, Invited Expert
Scribe: dbaron
Scheduling
==========
Rossen: We previously proposed to have January-February-ish F2F in
Seattle.
Rossen: We'd be happy to host.
Rossen: Unless people have a better location to propose.
Rossen: If we're hosting it, it would be in Redmond rather than
Seattle.
Rossen: If we don't have other offers on the table, we can do
Redmond -- or change later if we have other options.
Rossen: Still settled for Kyoto for following one?
Florian: Either Tokyo or Kyoto.
skk: Want to do Tokyo area.
Florian: Easier to meet developer communities in Tokyo.
skk: I'm talking to some Japanese publishers, we could arrange an
industry meetup.
Florian: I'll try to organize something in parallel in Kyoto to
see what we end up with.
skk: April or May?
dbaron: Might want to look for dates with conflicts.
Rossen: If you have conflicts around April/May, please send
conflicts to mailing list.
Florian: Are we necessarily CSS and Houdini, or just CSS?
Rossen: Don't know yet. Will discuss during Houdini meetings.
Round Display
=============
'shape' media feature
---------------------
<jihye> https://lists.w3.org/Archives/Public/www-style/2016Apr/0273.html
jihye: First thing is about the 'shape' media query, suggested by
Florian.
jihye: The device-radius query in css-round-display detects shape
of the display.
jihye: It lets us apply different styles according to display shape
jihye: but can't cover all shapes since it combines shape with
roundness of corners
jihye: so Florian suggested shape media feature.
Florian: We already talked at previous f2f about this.
Florian: Two reasons to query for shape: (1) if it's not
rectangular putting things at some places like corners
might not work, want to know about this to avoid corners.
Florian: we'd been discussing visibility(coordinates) query.
Florian: (2) stylistic reasons -- want round design if screen is
round
Florian: this media query is for that.
Florian: It tests whether the screen is round or not.
Florian: As of today the only OS that can let the browser know
about this is Android, and it has a boolean saying
round-or-not.
Florian: So it's all we can realistically implement.
TabAtkins: [joking] so we need to round off to the nearest value?
Florian: What I propose is rectangle or round media query.
Florian: We might fall back into yesterday's discussion.
Florian: This design assumes we have the "unknown" state.
Florian: If you have the Android API you know -- but otherwise you
really don't know.
fantasai: Presumably once you have screens that are really not
rectangular, you'll have new APIs.
Florian: This assumes unknown semantics which are close enough to
false.
tantek: Is this just for 2 dimensional displays, or 3d as well?
Florian: This is intentionally fuzzy -- not exact circle or exact
rectangle.
Florian: It's about whether round enough that round designs that
round designs are preferable.
plinss: ... 2d display wrapped in a 3d space.
Florian: ...
tantek: Using a simple term like round will mean different things
to different people.
tantek: If you saw the TVs at CES...
TabAtkins: Round is the correct short and easy-to-type word for
this.
plinss: Users perceive those as rectangular.
plinss: But there are also phones with screens that wrap around
the edge -- the edge is logically like a different screen,
but part of the same one.
Florian: This media query could be extended to a long list of
shapes, but it's about design trends that exist.
bradk: What's the chance the OS or browser will be aware of shape
of screen?
Florian: Android has a boolean that says round or not.
Florian: This is about design styles, not exact geometry.
Star-shaped displays aren't a thing.
Florian: If want to know what's hidden, need actual geometry of
screen.
Rossen: Why is it not rectangular or not in the query?
Florian: There isn't a design trend of putting circular designs on
rectangular screens.
Florian: People want to be round on round screens.
Florian: If there are star-shaped screens, we can discuss it then.
Florian: It's intentionally not a boolean query, so we can extend
the list if we need to.
Florian: We have 2 shapes for now, but can extend.
Florian: There's no false-y value in the list, so we can add more
if we need to.
Florian: If we give up on unknown semantics,
Florian: if you're a star-shaped UA and you know it, you can be
false for both rectangle or round.
bradk: I would think asking if it's a rectangle or not you might
want more stuff toward the center of the screen.
Florian: That's a separate problem about what points are visible.
This is about qualitative design.
TabAtkins: The screens that exist are rectangle, rounded-
rectangle, and round.
TabAtkins: We should not be in the weeds about all sorts of
bizarre shapes. MQ aren't the place for fine-grained
information passing. At some point you want a JS API.
Let's stop talking about stars.
<fantasai> +1 to not talking about stars
Florian: If we end up caring about other shapes, this is
extensible since it's not a boolean media query.
jihye: A question about your suggestion: if the UA doesn't knows
about shape of display, then shape:rectangle and
shape:round evaluate to unknown.
Florian: Yes.
dbaron: On some operating systems it may be reasonable for the UA
to know that the OS has rectangular displays and that's
that.
dbaron: You shouldn't try and say that if there is no API, then
the UA must not deny that is rectangular.
Florian: No, not trying to say that. Up to UA to figure out
whether or not it knows.
Florian: I'd assume that authors, in this case, knowing vast
majority of screens are rectangular. Authors likely to
assume rectangular if the UA doesn't know... but in that
case we expose full info to author.
bradk: From a practical viewpoint, wouldn't most authors assume
that if it's unknown, would assume it's rectangular.
Florian: I wouldn't have come up with unknown just for this, but
since we have it...
TabAtkins: Unknown only happens for unrecognized things -- we
don't have a semantic for known values being unknown.
TabAtkins: The assumption that if you don't know, you're
rectangular, is perfectly valid -- and we should define
that you're going to be rectangular if you don't know
that you're not.
TabAtkins: The thing that we gain is that naive code works just as
if it were assuming rectangular.
TabAtkins: We don't have a semantic for defined things returning
unknown and I don't think we want to add it.
TabAtkins: Unknown is just a way to not cancel out the entire MQ.
TabAtkins: We can just assume rectangular unless known otherwise.
Florian: I think it makes sense for authors to do that, but not UAs.
TabAtkins: What else would you do other than assuming rectangular?
Florian: If you're designing widgets for round screens...
TabAtkins: 99.9% of authors, if they don't know -- probably
rectangular. If OS isn't giving you information, assume
rectangular.
Florian: What do you gain?
TabAtkins: Simple semantics.
TabAtkins: If your screen doesn't know, it's rectangular...
tantek: I tend to agree -- better start with fewer values until
there's a case for more.
Florian: Fewer? I have 2.
TabAtkins: You're defining a third value that's "neither", that's
confusing.
TabAtkins: The unknown logical value acts in a counterintuitive
way if you don't know you're dealing with it.
jensimmons: I think there's a big difference for authors. We'll
have screens that know they're rectangles, that know
they're round, and those that have no idea.
jensimmons: Can we say that all the screens that don't know what
they are, definitely know they're rectangular.
jensimmons: Authors know how to deal with not having media
queries, e.g., on IE6, not knowing width.
jensimmons: ..
bradk: Danger is having code for rectangular screens that gets
excluded.
jensimmons: Risk that if every single screen ???
Scribe: TabAtkins
dbaron: I don't think this discussion about screens that don't
know what they are makes sense.
dbaron: I don't think somebody's gonna ship a browser UI that
works on a round screen without knowing they're doing so.
dbaron: So I think the only real risk is that somebody ships an
engine without updating it, because they updated the
browser UI and forgot about the engine.
dbaron: So we should just assume things are rectangular.
dbaron: Unless somebody knows they're on an OS they can detect
being round.
Scribe: dbaron
ChrisL: Asserting not knowing it's rectangular is ostrich-like --
we know the shapes of most screens.
tantek: Before mobile -- having unknown screen wouldn't have
helped with screen vs. handheld.
Florian: I think I have 2 counterpoints -- UAs that don't
implement this media query will behave the same as those
that implement rectangle as unknown
Florian: so I'm not sure it's useful to have different behaviors
between UAs that don't know about screen and those that
don't know about media query.
Florian: Having the same information in practice it's the same.
TabAtkins: I'm not interested in defining backwards-compat of
media query relative to their non-existence.
Florian: If you want to write a MQ for round design, query for
shape:round
TabAtkins: If we returned unknown, what should an author be doing?
Florian: In most cases it's useless to query for am-I-rectangle
Florian: If that's what you want people to query.
<tantek> this is silly, saying authors may do not(rect) is a
strawman
...
TabAtkins: What's the benefit of this more complicated unknown
value?
TabAtkins: What will authors assume if it's not round?
Florian: Rectangle.
Florian: In that case the MQ should be round: yes | no
TabAtkins: The unknown thing exists so we can do boolean logic
without breaking the entire media query and repeating
the selectors mistake.
Shane: I don't think there will be cases of people building
browsers for mobile devices without knowing the shape of
the device.
zcorpan: The case you're worried about is authors doing not
(shape:rect) and assuming circle and this will break if
we add a third shape.
zcorpan: I don't think we should use unknown value to protect for
that. We should have tutorials/notes that advocate using
only round.
hober: If the only query is rect, then you might ask for
not(rect), but if you have round, it's the obvious way to
ask the question of whether it's round.
hober: I think it's just a non-issue.
TabAtkins: What is the benefit to authors?
TabAtkins: Doing what you're suggesting is making it easier to
write it otherwise.
TabAtkins: I'll object to making known things unknown values as an
editor and implementor.
jensimmons: Useful to target rect.
Rossen: Anyone other than Florian who wants this?
Florian: Seems not, and I'm not objecting
Florian: I think better extensibility my way, but most of time
won't make a difference.
jihye: If the rounded rectangle that is not also round -- in this
case unknown?
Florian: If you're a rounded corner rectangle, the browser decides
if you're closer to a rectangle or closer to a circle.
fantasai: I'm worried about people using to see if it's a circle.
fantasai: Want to make sure querying what parts of the screen are
visible is [missed]
Florian: Browser on egg/ellipse that opt in to roundish designs,
that browser will want the roundish designs.
fantasai: We have just this and we don't have ability to query
what parts of the screen are visible, then authors will
use this to query what parts of the screen are visible.
TabAtkins: At first approximation, that's reasonable.
Florian: Might put things off corners ....
Florian: We might want MQ for geometry detection, but OSes don't
want to report that.
TabAtkins: MQ can't do fine-grained things.
Florian: We discussed this in Sapporo.
TabAtkins: I disagree with all that.
Florian: Back to question -- if neither strictly rectangle or
strictly a circle, it's a design choice of whether the
browser prefers round designs.
jihye: ?? idea of categorize the shape of round and rect only, and
not unknown?
fantasai: Should put a note in the spec that if a UA really doesn't
fit in these categories, should contact the WG so we can
add a new value
??: and should return false for both rect and round.
TabAtkins: That's what the advisement class is for.
Tantek & TabAtkins: ...
hober: The lesson from that is that we shouldn't add MQ without
having actual implementations.
tantek: Yes, don't add unless imminent implementation.
joone: Some round display are not perfect circle, e.g., Moto 360
has round display but bottom part cut out like flat tire.
joone: Many smart watch has round display but bottom part are ...
Florian: Maybe a MQ, maybe a JS API giving details of screen.
Florian: Also can't be implemented today because OS won't tell you.
joone: In some cases user cannot see bottom part.
Florian: I don't think this MQ is appropriate for circle,
circle-with-10px-cut-off-at-bottom, etc.
Florian: for that we need another query, as discussed in Sapporo.
Rossen: Florian, did you want a resolution on that MQ?
Florian: I think it would be good to resolve if we agree.
jihye: I would like to change device-radius to shape... is it ok?
Florian: This is instead of, not in addition, to device-radius.
Florian: Add this and remove device-radius.
Florian: Or other thing later.
TabAtkins: Or do something about that when implementations can do
something about it.
RESOLVED: Remove device-radius MQ, add MQ for shape: rect | round
with traditional boolean semantics.
jihye: We also need JS api to detect shape of screen.
jihye: In view of manufacturer, api to directly tell us what shape
of screen is.
<jihye> https://developer.tizen.org/dev-guide/2.3.1/org.tizen.web.apireference/html/ui_fw_api/wearable/circular_support/circular_support.htm
jihye: There are some APIs in Tizen (Samsung) OS.
jihye: They use these APIs to detect if screen is round or not.
jihye: Media query with window.matchMedia can know shape of device,
jihye: but we have to define media query before that to use that
jihye: so I suggest a new attribute to screen interface to know
directly
jihye: ... the shape of the device.
jihye: Something like round attribute can do that.
Florian: Why not use the media query we just defined from
javascript?
jihye: matchMedia?
Florian: Yes.
jihye: We have to define media query always to use that API
jihye: but when we implement scrolling effect, we mostly implement
it by javascript.
florian: But media queries are accessible from javascript.
fantasai: I think she's trying to say it's harder to polyfill.
TabAtkins: We're not going to throw in arbitrary new APIs to
handle all new media queries.
zcorpan: Authors typically feature test things using something
like modernizr, which has its own API
zcorpan: Authors could use modernizr.screenshape.circle -- could
use matchMedia if supported or fall back to polyfill if
not supported.
Florian: jihye, what's the problem for you with using matchMedia?
jihye: I think matchMedia can do that.
Florian: The syntax is ugly, but that's not specific to round
shapes.
Florian: Side question, is this something typed OM from Houdini
can fix?
TabAtkins: We're not currently planning anything for media queries.
shane: But we'll need to have a typed interface to media queries.
shane: Won't help with keywords, but will help with lengths.
Rossen: Next topic, then? More to discuss?
viewport-fit
------------
<jihye> https://drafts.csswg.org/css-round-display/#extending-viewport-rule
<astearns> https://drafts.csswg.org/css-round-display/#viewport-fit-descriptor
jihye: we need to define viewport-fit
Florian: it's a descriptor in @viewport
<zcorpan> @viewport { viewport-fit: ... }
jihye: I wrote spec for this in round display.
jihye: On rectangular display viewing area is screen rectangle
jihye: but on rounded display viewing area is not always bounding
box of screen
jihye: viewport-fit ...
jihye: On round display, if viewport-fit is cover, use rectangle
that covers entire display
jihye: but if viewport-fit: contain, on round display, viewing
area is inscribed rectangle.
jihye: How can we call the viewing area?
jihye: We can call viewing area as the visual viewport.
jihye: There is only initial viewport and actual viewport in the
device adaptation spec.
jihye: we have to add new term, visual viewport.
jihye: In this visual viewport, the viewing area [missed]
Florian: As currently proposed, why do we need this at all?
Florian: One problem we have with round displays, is that without
anything, viewport is bigger than screen, and you have
areas that are not visible.
Florian: For CSS we've been writing so far, by default things are
readable and not hidden off screen.
Florian: If you don't style for specific device, still get
something usable.
Florian: So by default should get something readable by default.
Florian: So by default fit the viewport in the screen, and then
have a switch if you can deal with the corners being
hidden -- media queries, shape-inside, etc.
Florian: If you don't, safe by default.
Florian: How does this proposed thing work?
Florian: If you do viewport-fit: contain or cover on a rectangular
screen, you get the usual results.
Florian: On a round screen, it influences the initial viewport (as
defined in device adaptation), should probably talk about
as initial layout viewport.
Florian: It's what you have before you apply the constraining
procedure.
Florian: Once you're done with that the visual viewport is also
sized to that size.
Florian: So you if you have other stylesheet rules that ask for a
viewport that's 1000px
Florian: then your layout viewport will be larger and go where
ever it wants, but your visual viewport will be inscribed
in the screen.
Florian: If you do cover then you get the opposite, then layout
viewport and visual viewport will contain the round screen.
Florian: There's a third value proposed in the spec which is auto
Florian: which should be implemented as contain if you don't have
a better idea, but it allows browsers to say that this is
a waste of screen real estate, usually nothing in the
corners anyway.
Florian: So do something somewhere in between that cuts the
corners a little and uses much more of the screen and
only hides a bit of the corners.
Florian: In addition, if you're in auto mode, you can have an
extra scrolling mechanism.
Florian: If the user drags to try to see what's in the corners,
lets the users drag to see all of the visual viewport
Florian: but if you don't have anything smart to do, just stick to
contain.
Florian: Maybe we need a word for the screen, unless screen works
fine, or maybe we need a word for the bounding box of the
screen, or maybe that works.
bradk: When is the visual viewport not the initial viewport?
Florian: Initial viewport (should be changed to initial layout
viewport), in the world where everything is rectangular,
is the size of the screen.
Florian: Maybe in the UA style sheet maybe there's a rule forcing
it to 800 or 900 pixels to deal with mobile devices.
Florian: After the constraining procedure the actual layout
viewport is what was in the UA style sheet, unless author
says to make it fit. That's how it's now described in
device adaptation.
Florian: Then you view this through your visual viewport (term not
actually in spec).
[bradk asks questions about viewports]
Rossen: Physical and layout are different if you're pinch-zoomed
for example.
Florian: All this terminology is fuzzy; visual viewport not
discussed anywhere in specs.
Florian: Most of things in spec that talk about viewport talk
about actual layout viewport -- but not quite all;
Florian: some refer to visual one.
Florian: Maybe in background-attachment???
Florian: Visual viewport has same dimensions as initial layout
viewport
Florian: but easier to think of them as separate things.
Florian: I'm mostly going by terminology used by ppk on his blog,
inspired by internal terminology at Opera.
[ discussion about what goes in the unused space ]
bradk: Authors will want to put things there.
Florian: OK for UA to put background color there, but authors
shouldn't rely on that.
bradk: If I have control, I'll use cover so I can control what's
in that space.
Florian: That's fine. But if you take Web pages designed prior to
round displays, don't want half the text to be hidden.
bradk: I want something in between, I can put things there but can
rely on important being contained.
plinss: You don't get control if it's outside the viewport.
bradk: How come I get control over that space if I say cover, but
not if I say contain?
TabAtkins: There's nothing underneath there -- since any arbitrary
webpage *can* draw there.
Florian: Web page can request full screen.
TabAtkins: With permissions only.
TabAtkins: Let's not pretend the whole viewport isn't under their
control.
Florian: I'm ok with a MAY that the background extends -- not
necessarily controllable space.
dbaron: I think Brad has a good point.
dbaron: The author is specifically choosing to say "I don't know
how to fill that space"
dbaron: So it's not clear why the UA should then say "ok, then
you're not allowed to touch it at all"
fantasai: We can reuse similar functionality to @page which lets
you touch the margin area.
fantasai: Could use @page.
bradk: It sounds like the only way to get what I actually want is
to use cover and do JS math.
<fantasai> I think this should be under the control of the UA. It
MAY extend the canvas to bleed outside the viewport
area, if it wants.
Florian: How much do we allow to link out?
TabAtkins: Yes, it's still addressible area
Florian: Contain is the default value.
Florian: It's the compatibility mode.
[discussion of negative positioning just off the edge]
plinss: People sometimes put things just off the edge so they can
transition it on-screen.
Florian: I'm open to leaking canvas color to that area, but not
any of the other stuff.
zcorpan: It seems reasonable to me to hide the unscrollable area
but show the scrollable area part of the screen.
zcorpan: You have 2 directions that are unscrollable, typically
above and left
zcorpan: but you can scroll right and down -- not reason to hide
these.
zcorpan: Kinda ugly, but just accessible fallback.
bradk: But once you scroll...
zcorpan: Yes, once you scroll down, can render things at the top.
Florian: This is not dangerous -- but is it ugly?
TabAtkins: Minus the canvas that escapes the element, root element
is contain:paint by default.
TabAtkins: The objection was the elements are outside there --
they'll look ugly.
Rossen: For clipping purposes, containing block is still clipping
in negative scroll direction.
TabAtkins: ICB clips its contents (elements, etc), but canvas
background still renders.
<TabAtkins> that feels like it'll look good
dbaron: We're doing UX design here, and that's not something we
should be doing here.
dbaron: We should have other people design the right thing for
round displays, and experiment with products, and then
come back to this group.
dbaron: It's not clear to me that this is the right thing.
bradk: so we should just punt on this?
Florian: I see your concern, but my concern is that if we do that
we'll end up with Web for Watches and Web for Everyone
Else.
TabAtkins: The relevant people implementing things are in this
room or adjacent to this room.
TabAtkins: We have examples of this not working well,
<meta viewport> is a trash fire.
Florian: With variants discussed today, this is one proposal to
avoid having at trash fire.
Florian: Do we want to write it up as a proposal and at risk?
Rossen: In favor of not influencing it now.
jihye: We first proposed contain, guarantees element contained in
screen
jihye: so you can guarantee that all the elements are in the screen
jihye: We need that design when we implement scrolling.
TabAtkins: So have you tried to implement contain yet?
jihye: Not yet.
jihye: We do that by javascript translate.
TabAtkins: So you do show what's in the background of the page in
the areas that aren't covered.
jihye: We divided the pages with grid.
jihye: We don't use that space.
TabAtkins: What shows in the space?
jihye: Maybe transparent?
Florian: One option is don't write anything in the spec; let LG
figure out
Florian: or, write something loose in the spec giving some
guidance and letting implementors figure out details
Florian: or write exactly what I like.
plinss: I think middle solution.
plinss: Write up problem and possible solution and being open to
improvements.
plinss: I'd rather give some guidance and leave details up to UX
experts.
jensimmons: Seems to me that doing absolute simplest thing
possible might be good direction -- and contain --
just make it tiny.
jensimmons: This isn't at all what I thought it was when I read it.
jensimmons: If I want to design a layout, and have background
colors show up in the extra space.
jensimmons: Smallest thing -- take a website and make it small and
maybe put black around it
bradk: Not sure making it small is the best thing, though
Florian: Contain is meant to be the default.
bradk: I'd rather see the default be cover.
Scribe: fantasai
plinss: Auto can do what cover would do, if you have the ability
to scroll to see all of it.
dbaron: I think we need a switch to say whether the page was
designed with round displays in mind or not.
dbaron: And I think we should leave it up to people who are trying
to build a good UX on round display, to figure out what
the best thing is to do for a Web page designed for not a
round display.
plinss: What's the trigger?
dbaron: Could be something like this.
fantasai: That's why we have 'auto' as the initial value.
dbaron: Maybe we should just have 'cover' and 'auto'.
TabAtkins: That's fine.
Florian: And some notes that if you have no idea what to do, do
contain.
Florian: Should we say, "however you do it, you must show all the
content".
dbaron: UA must provide a reasonable way to show content that has
not been designed for round display.
Scribe: dbaron
jensimmons: Another variable here that might or might not matter --
some sites use and don't use media queries.
jensimmons: Some pages have made designs that are made to work on
150px wide screen.
Florian: Width and height media queries work just fine here.
Rossen: Where is this going to go into which spec?
Florian: Round display spec for now, but when both this and the
natural host are stable enough, can shuffle around.
Rossen: Action for jihye?
Rossen: Proposed resolution on having viewport-fit: cover | auto,
with loose guidance for auto that says the whole Web page
should be viewable.
bradk: [question scribe missed ]
fantasai: proposal is to accept viewport-fit with cover and auto,
and auto must require that content can be made visible
and handle pages not designed for round displays.
fantasai: I agree with this.
fantasai: One thing w.r.t. contain is some websites where you want
the whole viewport visible at all times, like a game,
you don't want the UA to do smart scrolling.
fantasai: So I think author should be able to opt in to strict
containment for certain types of things,
fantasai: pick a rectangle that's inscribed.
fantasai: What you do with the space outside of that rectangle is
up to UA.
fantasai: Can use canvas background, @page background, pick first
background image, whatever they want.
fantasai: I think that for certain types of Web pages they might
want to opt in to having entire viewport always visible,
in that case contain is your best option.
bradk: So saying that if there's no scrolling mechanism you should
always have the entire page visible?
fantasai: Contain should be about the visual viewport visible
entirely on screen.
Florian: I agree with that about making the visual viewport fit in
the screen; we already have viewport-width:auto to make
the layout viewport fit in the visual viewport
<fantasai> 1) Accept viewport-fit with three values: cover,
contain, auto
<fantasai> 2) Initial value is auto. UA can do anything it wants
as long as the content not designed for round screens
is easily 100% viewable by the reader
<fantasai> 3) Undefined what is outside the contained viewport for
'contain'. UA can paint anything it wants, chrome,
black, canvas background, @page background, photo of SF
Bay Bridge, whatever.
Florian: I'd add -- not sure if needs to be part of the resolution
-- add note that these are early thoughts by the WG.
Requesting feedback.
bradk: Note that if you use contain, that most webpages will be
unreadably small
RESOLVED: 1) Accept viewport-fit with three values: cover,
contain, auto.
2) Initial value is auto. UA can do anything it wants as
long as the content not designed for round screens is
easily 100% viewable by the reader.
3) Undefined what is outside the contained viewport for
'contain'. UA can paint anything it wants, chrome,
black, canvas background, @page background, photo of
SF Bay Bridge, whatever.
<br duration="calc(15*60s)">
<MaRakow> Florian, fantasai: noticed before lunch the
@viewport/@page issue was discussed -- Edge does support
the mentioned behavior for @viewport but we're not
entirely satisfied with it -- I think it needs some
thought on how to make the behavior more understandable
to authors
Polar coordinates
-----------------
Scribe: zcorpan
jihye: So far as we discussed I think there are some ???
jihye: There is 2 points of disagreements:
jihye: 1) I think polar-anchor can be used in polar layout
jihye: 2) the way the polar-origin works
jihye: Polar-origin can decide the pole of the polar coordinates.
jihye: The element can be decided by the polar-anchor.
bradk: Polar-origin you're putting in a value and the end result
is that the element is shifted over;
bradk: the current spec it's not shifted over by the amount you
put in.
bradk: I'd like that to be more direct, so that if you shift it
3px to the right, you set the polar origin 3px and 0px (
rather than -1.5px)
bradk: I'd also change the name to "nudge."
bradk: The effect is that you move the element.
bradk: It's using percentages by itself.
Florian: So it's anchor?
Florian: The one that's related to the container is origin,
Florian: these names are confusing.
bradk: Yeah.
bradk: You're right.
bradk: Origin is relative to CB.
bradk: Forget what I said earlier.
Florian: I think what we've said so far, the direction you move
into is polar angle.
Florian: The distance and angle work from there.
Florian: The default is auto.
Florian: If you set center, the center is of the CB.
Florian: Polar-anchor lets you use some other point of the element
to place the element.
bradk: Percentage resolving is just for the anchor.
Florian: If we switch to the model you're proposing then it's like
transforms but in ???
bradk: You're adding an additional movement to it.
bradk: The end result is the same, you're just moving it.
fantasai: Let's say we want to position it ???
fantasai: The center of the box is 125,125
fantasai: The positioning scheme that backgrounds use require you
to ???
Florian: If you want to be at 25%,25% it would start at 0,0 and to
do this in polar anchor you do -25%,-25% because you're
moving the point.
fantasai: It's what relative positioning does.
Florian: The difference is whether it's relative to the element
itself or CB.
fantasai: I don't like having yet another way to do relative
positioning.
fantasai: If we want a generic shift this thing by xxx, we need a
different way of measuring, not a different way of
shifting the element.
Florian: The difference is if we're not doing positioning, we
already have transforms.
Florian: The distance that doesn't stick you out of the container,
not taking transforms into account there is weird.
Florian: For the sake of polar positioning we need something like
transforms but happens at layout time.
bradk: Why do we need it for polar but not in general.
bradk: We need something that nudges it over...
fantasai: I want to align this point of the box to another point
of the container
fantasai: by default it's the center.
fantasai: We could say it is like background-position
fantasai: or we can have a switch between the two.
fantasai: Yes you can use transforms to get the same effect
fantasai: but we're not trying to nudge the element.
fantasai: You only need this if you need the points working
together.
Florian: Polar-distance has a switch, which is 100% means don't
overflow, move as far as you can without overflowing.
Florian: That operation can't reasonably take transforms into
account, therefore it can't be using transforms.
fantasai: Right.
Florian: Because transforms are out, we need to use polar-anchor.
bradk: It seems weird that we have this thing that does the same
thing as transforms but only for this other thing.
Florian: There are many ways you can move things around the screen.
This is a different model.
fantasai: I'd like to drop `??? value and instead have the initial
value of polar anchor be auto.
fantasai: So that 50% places it in the center, 100% places it as
far as it will go without overflow.
fantasai: If you want to center you say "center"
fantasai: like backgrounds.
fantasai: For shifting things around then also allow you to set an
explicit point.
Florian: Why doesn't it stick out?
Florian: For polar-origin: center; polar-distance: 100%
Florian: That's what contain is for.
fantasai: ok.
Florian: There are 2 ways to do that.
Florian: One can stick out and the other not.
bradk: I think contain is still weird.
bradk: What you end up wanting is that the center of the element
to line up in a circle?
bradk: Not so much the ends.
Florian: There are varying behaviors you may want.
Florian: Sometimes you want it to stick out and sometimes not.
Florian: I think this is also a tricky discussion
Florian: If we want an auto value that does some magic but that
sounds weird to me.
bradk: Maybe the polar-anchor if it's 100% would be 100% of the
distance of the polar-distance?
Florian: ???
TabAtkins: I'm happy with contain being on polar-distance, seems
reasonable.
TabAtkins: Seems like the right place for it.
Florian: I'm suggesting that when polar-distance is a percentage.
Florian: We should have a few keywords for what 100% means.
Florian: Is it against the edge, same distance in all directions
or follow the edge?
Florian: Which switches we need can be discussed.
TabAtkins: Put if far out but make sure you can still see.
Florian: These switches make sense as keywords.
Florian: Trying to do that with polar-anchor is wrong.
Florian: I think using transforms is also wrong.
Florian: To do nudge instead of anchor, I think that only makes
sense if there's a usecase outside polar coordinates
where .... would not work
bradk: You may want to use it on something else, like animate.
bradk: That would apply to anything
bradk: If you need to move it a little bit one way or the other to
get the position just right, why does it not apply to other
things?
bradk: To me it seems if you want to limit it to polar you need to
justify why it only does that.
TabAtkins: For round screens you need geometry ????
bradk: You can use polar-origin to move things around in a box, to
center it.
Florian: Polar-distance: 0 puts you in the center.
bradk: You can use polar-origin and polar-anchor together.
bradk: People will use them to center or whatever using the
percentage of the CB.
Florian: Polar is generic, switching the name makes it more
general, is your point?
bradk: Yeah.
bradk: If you want to move something 3px to the right it shouldn't
be negative, it should be just 3px.
Florian: It would be harder to use for the intended use case.
TabAtkins: Can we move this to hallway conversation? It's just 4
of you discussing this.
Rossen: If the conversation has proven to be ineffective for the
past year we should maybe discuss this.
shane: Can we give them 2 mins each to present their case. arguing
like this doesn't help?
Florian: Should we write or say this?
shane: Prepare at lunch, present after lunch.
fantasai: My proposal is what we resolved on in Sydney, it's
written up.
[Continuation of topic after lunch break]
Scribe: ChrisL
fantasai: Over lunch, looking at motion-path, open issue for
motion-origin which pegs a point on an element to the
path.
fantasai: Very similar to polar-anchor property.
fantasai: In fact these are basically the same: polar-angle
implicitly defines a path
fantasai: polar-distance is like motion-offset.
fantasai: So we should combine them, have motion-path accept an
angle as well, then merge the rest of the properties.
fantasai: Resolves the issue in the spec.
fantasai: "and rename all the properties of course" (flames,
fireworks, kaboom)
fantasai: (draws on board)
<dbaron> whiteboard:
https://lists.w3.org/Archives/Public/www-archive/2016May/att-0000/whiteboard.jpg
fantasai: Also we said, what about making offset-anchor easier so
make it behave like background-position by making the
initial value 'auto' instead of center--uses point that
corresponds to the percentage in offset-origin,
fantasai: so it takes the same syntax as background-position.
fantasai: This combines two positioning systems, solves the fact
that the motion stuff is not actually about motion, and
we have a combined model
fantasai: and we can position elements using the background-position
model which authors are familiar with.
TabAtkins: You're missing the rotation property.
fantasai: we can add it
TabAtkins: We don't need <angle>, SVG has bearing commands now.
shane: Motion is 0 to 100%, you may need a length value.
Florian: Keywords like closest side, etc
bradk: Contain as the default.
TabAtkins: No contain anymore. And contain in transform space is
more difficult.
fantasai: Not sure why.
Florian: Contain keyword on polar-distance would be on offset-path
which defines the path.
fantasai: Origin for path is set by positioning / offset-origin,
calculate path according to keywords to set the length.
offset-distance says how far along the path.
dbaron: Does motion-path have relative vs absolute paths?
TabAtkins: auto-adds an initial M
ChrisL: SVG path always defines the starting point of the path.
?: motion-path always appends to the transform starting from the
current position.
hober: Motion-path is fancy transform, and doesn't affect layout -
does this?
TabAtkins: Does not affect layout except for scrollable area.
hober: ok
Florian: Other transforms are after motion-path?
TabAtkins: Yes.
shane: So we define what a percentage means...
fantasai: Yes.
fantasai: polar-distance & motion-offset -> offset-distance
fantasai: polar-angle -> offset-path
fantasai: polar-anchor & motion-origin -> offset-anchor
fantasai: initial value of offset-anchor is auto
fantasai: which copies the percentages from offset-origin so
offset-origin behaves like background-position.
Florian: offset-path newly takes an angle plus a keyword (as yet
undefined list, including contain).
bradk: To go out at an angle, the offset-anchor is where?
Florian: You start where you are.
bradk: For motion-path it is the center.
Florian: Same, for straight lines.
bradk: Not for curved ones.
jihye: There is also a side.
Rossen: sounds like a good proposal now.
RESOLVED: accept current proposal as outlined by fantasai
shane: names TBD
<jihye> in current spec of round display, there is <side> value in
polar-distance
<jihye> the concept of <side> also can be used in offset-path
hober: We should tell fxtf that we did this :)
shane: Apart from naming, this is a functional superset
shane: The only thing we've changed is (1) addition of angle to
offset-path and (2) naming.
Florian: Does offset-origin go into motion path spec?
fantasai: Spec needs renamed, it is not about motion. It is
positioning -- path positioning. It can be used to
build motion if you animate.
Rossen: Spec to be renamed.
shane: I can make these changes.
jihye: Happy with this resolution.
[and there was much rejoicing]
fantasai: Add jihye as motion path editor?
jihye: It would be an honour.
RESOLVED: jihye added as an editor of Motion Path spec
Received on Thursday, 26 May 2016 00:05:17 UTC