- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 18 Nov 2015 20:38:32 -0500
- To: www-style@w3.org
Logical Properties and Values
-----------------------------
- fantasai introduced the proposed syntax to add logical keywords
for background images. The group needed more time to review,
but had some initial feedback:
- There were some hesitations about 'start' and 'end' as single
values, since background-position normally defaults the
second value to 'center', rather than duplicating it.
- Since the initial values of the physical and logical
properties don't match, the logical properties will need to
not have an initial value.
- RESOLVED: Make logical coordinates always block, then inline,
even though physical coordinates in background-
position are horizontal, vertical.
- RESOLVED: Properties affecting position of border-box (i.e.
stuff outside the border edge) cascade by the
parent's writing mode; stuff affecting inside the
content-edge of the element keys off of the element's
own writing mode. border/padding/sizing TBD
Next F2F Meetings
-----------------
- Since TPAC is in September in 2016, it was thought that the
group may only want three F2F meetings in 2016 or, if they do
a fourth, it would be in December.
- RESOLVED: 2nd week of May, 9-11 (with possible Houdini 12-13),
anywhere on US west coast. Host TBD.
- The chairs plan to arrange for breakout meetings during the F2Fs.
- Rossen will send out a survey to figure out topic tracks and
analyze participant overlap.
- Space may be a limitation for this approach in Sydney, but
whomever hosts the May meeting should plan on having at
least two rooms available.
- There was an expressed desire for any resolutions coming out
of a breakout to be tentative until they're reported back
to the whole group and affirmed.
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/tpac-2015#agenda
Scribe: Bert
Logical Properties and Values
=============================
Background Position
-------------------
<dbaron> https://drafts.csswg.org/css-backgrounds-4/#the-background-position
fantasai: First one is background-position.
fantasai: We had requests from I18N WG to add logical keywords for
background images.
fantasai: (among other things)
fantasai: There are longhand properties.
fantasai: I came up with a syntax [see draft].
fantasai: You can pick direction within an axis.
fantasai: [shows examples]
fantasai: background-position: x-start
fantasai: background-position: left
fantasai: background-position: start 10px
fantasai: People probably need more time to look at this, but
initial reactions?
[discussion about physical-logical mix]
TabAtkins: Florian once asked for 'top x-start'
stevez: This is mostly to be able to distinguish when used in the
short hand.
dbaron: I'm a little hesitant about the one-value syntax with
'start' or 'end'.
fantasai: Yes, you default to center for the 2nd value normally,
but 'start' duplicates itself.
fantasai: And 'end' too.
dbaron: Given that center is the default for 2nd in other cases,
I'd prefer simply not allowing a sole 'start' or 'end'
TabAtkins: I'd be OK with that...
fantasai: I'd like to allow them, because I don't see why not. And
duplicating is a common pattern for CSS properties.
dbaron: ...except for background.
johannes: [missed]
fantasai: This topic is not only about background, also floats, e.g.
leaverou: It does make sense to mix them.
dbaron: Back to background:
dbaron: I see two bigger problems.
dbaron: One is that before top and [...] were mutually exclusive.
That seems to be no longer the case.
dbaron: Maybe not a problem.
dbaron: Some longhands may not have an equivalent short hand.
TabAtkins: That happens sometimes.
fantasai: What case?
dbaron: If you mix background-position-x and
background-position-inline.
TabAtkins: It is fine to have values that cannot be expressed in
shorthand.
dbaron: Probably it's OK.
fantasai: We found initial values did not match easily. Unlike for
margin, e.g., where the initial is 0.
dbaron: Can say that logical property has no initial value.
fantasai: Is that possible? In that case OK.
stevez: need to explain what not applicable means.
stevez: In general module about properties syntax.
dbaron: [typing text]
2-Axis Positions vs. 4-Direction Shorthands
-------------------------------------------
<fantasai> https://lists.w3.org/Archives/Public/www-style/2015Oct/0212.html
fantasai: TabAtkins and I noticed we could not keep track of which
came first when using two-value syntax.
fantasai: Background and border-spacing have horizontal then
vertical.
TabAtkins: Logical ones start with block then inline.
TabAtkins: I always write it wrong.
TabAtkins: So we have issues and no satisfactory answers.
fantasai: Grid-area vs grid-template...
TabAtkins: Options A an B
[A. Splitting the bucket so that:
block/inline => grid-area, margin, padding, border, offset,
[ other 4-value ]
inline/block => grid-template, background-position,
scroll-snap-align, [ other 2-value ]
B. Making logical coordinates always block, then inline, even
though physical coordinates in background-position are
horizontal, vertical.
background-position: start end; /* block, inline */
margin: 1em 2em relative; /* block, inline */
]
stevez: Always block before inline seems easy to remember
TabAtkins: Some properties have four values and two values.
fantasai: We should go back in time and tell Hakon and Bert that
background should be consistent with other properties.
Florian: With Option B, we don't have a time machine to go fix it,
but we can travel to a parallel universe where everything
works correctly.
Florian: Is this an incentive for people to start using logical
properties?
TabAtkins: Any objection to option b, block before inline?
RESOLVED: Option B (Make logical coordinates always block, then
inline, even though physical coordinates in background-
position are horizontal, vertical.)
ACTION TabAtkins update grid with this resolution
<trackbot> Created ACTION-730
Cascade of Physical and Logical Properties
------------------------------------------
<astearns> https://drafts.csswg.org/css-logical-props/#property-index
fantasai: Next issue is cascade of physical and logical properties.
fantasai: The spec is currently a mess.
fantasai: The problem is which writing-mode the property is
relative to.
fantasai: We discussed this before.
fantasai: The complexity comes from that there is no perfect answer.
fantasai: The simplest answer is use writing-mode of elt itself.
fantasai: Easy to understand mapping,
fantasai: but many rules reference CB.
fantasai: E.g., drop margin based on CB,
fantasai: Float start will float to start of CB,
fantasai: Alignment follows container instead of grid item itself.
stevez: writing mode applies to [...]
Rossen: All the examples you gave make sense to reference CB.
Rossen: Everything from border inside makes sense to refer to elt
itself.
fantasai: Border itself could be either.
fantasai: Inside the box, e.g., text-align refers to writing-mode
of elt itself.
fantasai: If box has has margin on end but different writing mode
than CB, then margin may not disappear where it should.
[ Example was 'float: start' with end padding/border/margin to
create separation from non-floated content. If the surrounding
content is LTR and the floated content is RTL, then the end
padding/border/margin ends up being on the left side of a left
float. ]
fantasai: That causes frustration for authors.
fantasai: In that case you use the parent, because difficult to
compute layout of CB.
Rossen: Really it only applies to positioned elements.
[ Parent is only incorrect if CB skips ancestry with a
'writing-mode' switch--expect this to be an exceptionally pretty
rare case. ]
Rossen: It means static position is still computed to parent.
fantasai: No, this is about cascading.
fantasai: Most things that have longhands work better against CB.
fantasai: Pretty much everything in the draft.
fantasai: Orthogonal flows are going to be a small percentage of
cases.
Rossen: Block and inline size should be kept in @@@
TabAtkins: Both seem reasonable: sometimes want to set content
size, sometimes want all siblings the same size,
independent of their writing-mode.
stevez: Example of counting in number of lines.
johannes: You want images of a certain number of lines?
stevez: I'm thinking of a table, with one cell in Japanese.
fantasai: You can always still use the physical properties.
fantasai: Auto will shrink wrap; explicit size, like 50% keys off
surrounding size.
fantasai: Is percentage referring to horizontal or vertical
dimension?
fantasai: You want 50% in inline dimension and auto in block
dimension.
johannes: If you could specify lines, might want float of 10 lines
high.
florian: Say you have a magazine layout, with some boxes in
different direction, but all specified to parent which is
always in same direction.
TabAtkins: You can have a keyword 'self' when you want to be refer
to elt itself.
koji: I see both cases exist, but not sure which case is more
common. My instinct is to agree with szilles.
stevez: I disagree with myself and now agree with TabAtkins.
fantasai: Say I have simple, one-flow document. I want a block of
50% and then lay something out inside it.
Rossen: Say you have a rtl container, inside it a ltr container.
Rossen: And set 1em padding on the end.
Rossen: Now you say I end up with 1em on the end.
Rossen: That makes no sense to me.
TabAtkins: Browsers have had different default margins and
paddings, e.g., in lists.
Rossen: With physical properties you can get away with that.
florian: When you have float, size and margin refer to CB, agreed?
Rossen: Yes, but everything inside the border refers to elt itself.
Florian: If you put some margin between yourself and parent, you
may want the margin to be on the same side for all elt.
stevez: Do we agree that everything from border out refers to
parent?
florian: The blue border in our property definitions in the spec
style should refer to parent.
stevez: We agree on borders: borders are on outside.
stevez: And we can discuss about the other pieces.
r12a: You can have borders on spans, too.
r12a: Don't you want the border relative to the text?
TabAtkins: Some properties are arguable both ways.
TabAtkins: We have a convention for that.
dbaron: We are over-analyzing the example.
dbaron: In most cases there will be multiple relatives.
dbaron: Is the elt with the border the same as the elt with the rl
text?
dbaron: Many structures will have multiple elts.
TabAtkins: And sometimes not. e.g., <li> is often just naked text.
johannes: When we talked half a year go or so we thought it was
strange margins would go on other side and we thought
let's just put in a <div>.
johannes: The extra <div> allows you to change the inner one
without problem.
stevez: The issue is can we have a simple rule, while still
allowing people to set it up the other way.
stevez: A simple rule that people can remember.
rossen: In general it seems our implementation follows stevez's
rule, border and everything out is relative to CB.
dbaron: But we're talking about parent not CB now.
fantasai: Look at quotes: they use punctuation of the context
language.
fantasai: Border is similar.
stevez: If Arabic text in an English context is broken over two
lines,
stevez: I still want English rules.
fantasai: All our rules are designed around CB.
rossen: I'm only talking about the case there is a switch of
writing-mode, otherwise there's no difference.
fantasai: In Japanese, writing-mode switch in side notes, caption,
table headings, is quite common.
<karl> example of Japanese Typography
<karl> http://la-grange.net/2007/07/23-japanese-typography
stevez: We are talking about a general rule. There may still be
other use cases.
rossen: Positional properties, such as margins, it makes sense to
me to be relative to container.
rossen: Sizes make sense to be relative to elt.
stevez: That's why I want to agree on the outside case first.
stevez: But I understand r12a's use case.
fantasai: everything from border-box out.
rossen: that includes alignment, float alignment...
fantasai: inside the content-box belongs to element.
<fantasai> Seem to have consensus on properties affecting
positioning of the border box being wrt parent writing
mode
<fantasai> Seem to have consensus on properties affecting inside
the content box being wrt element's own writing mode
stevez: So we have disagreement on border and padding.
florian: We also disagree on size.
fantasai: text-indent is inside.
TabAtkins: Proposed resolution: Everything outside the border-box
is resolved relative to parent's writing-mode.
astearns: Let's do whiteboard discussion outside this meeting.
bert: And that says "parent" not "CB" is that correct?
TabAtkins: Correct.
fantasai: Implementers see margins as positioning, different from
border and padding. Authors see it as similar to padding
and border.
leaverou: New authors confuse margin and padding a lot.
leaverou: Experienced uses see them as margins as separate from
borders and padding.
florian: Given margin: auto can affect the size of the element,
it's weird to treat them differently.
rossen: Margins never influence the width.
florian: If margins are outside and relative to parent [...]
rossen: You want to set what exactly?
florian: Width to specific value, relative to parent.
rossen: Don't see that use case.
johannes: There are rules for how many characters per line and how
many lines minimum. Then you want all measurements
relative to outside.
florian: Character grid rhythm.
stevez: So it seems we can agree on the proposed resolution.
RESOLVED: Properties affecting position of border-box (i.e. stuff
outside the border edge) cascades by the parent's
writing mode; stuff affecting inside the content-edge of
the element keys off of the element's own writing mode.
border/padding/sizing TBD
fantasai: I think that is it for the major issues. Rest is tons of
issues to edit.
astearns: So what topic next?
fantasai: We have i18n people here, any topics related to that?
r12a: I have no issues at the moment.
fantasai: snap points with logical keywords.
matt: I think all the x/y stuff is gone already.
Rossen: Snapping is more of a positional property.
Rossen: Something consistent in the parent scrollable.
Rossen: Calling it start rather than left makes.
bert: I want to be able to just say 'left' as well.
matt: The only thing in spec that implies logical is positioning.
fantasai: Larger discussion, 1D vs 2D and things.
Rossen: wrt Bert's issue: If I specify left and than transform,
where is the snap point now?
Rossen: Left refers to bounding box.
matt: I think we don't need to edit anything in the spec for this.
fantasai: If we split into scroll-snap-area and -align...
matt: No actual text change.
fantasai: Either way we'll add logical stuff. That probably solves
that problem.
Next F2F Meetings
=================
astearns: TPAC 2016 is in Sep.
astearns: So no sense in an Aug F2F.
glazou: There was a suggestion to have a meeting in Sophia-
Antipolis between Feb. and TPAC.
glazou: Probably only 3 ftfs next year.
dbaron: We can also have a meeting in December.
glazou: But avoid blizzards :-)
TabAtkins: Holiday travel is problem.
Florian: TPAC is not on Halloween, so can do ftf on Xmas :-)
skk: Can host at Keio around June.
dbaron: AC meeting is in March in Boston.
john: June is not so good for Mozilla.
dbaron: Whole of Mozilla will be in London June 10 to June ?
dbaron: Adjacent weeks may work, depending on location
<dbaron> Moz folks will be in London June 13-17.
dino: Apple can host early May in Bay Area, or after mid June.
dino: May is not guaranteed.
fantasai: So many companies are in the Bay Area, if Apple can't we
can find another.
dbaron: The mid point between Feb and September would be end of
May begin of June.
dino: That would not work for Apple, Apple conference.
rossen: Besides Apple, other organizations with constraints on
that time?
<dbaron> There's actually not an exact midpoint -- the midpoint
between the February and September meetings is halfway
between meeting the week of May 23-27 and the week of May
30 - June 3.
dino: If you pick a day, I can see if I can host. And if not, we
can definitely still send someone to the F2F.
TabAtkins: Late May is probably Google IO - bad for hotels in Bay
Area.
astearns: Sounds like 9-11 May
dino: Should we have a Houdini meeting, too?
glazou: Then take whole week.
Rossen: Last time, San Diego was wonderful
astearns: So 2nd week of May, and we'll find out who can host.
[1st week is Golden Week in Japan]
dbaron: So going *to* Japan at the end of that week could be
expensive.
Rossen: Proposal is 2nd week of May, 9-11 (with possible Houdini
12-13), anywhere on US west coast.
Rossen: Host TBD
RESOLVED: 2nd week of May, 9-11 (with possible Houdini 12-13),
anywhere on US west coast. Host TBD.
Rossen: We talked about short meetings. In parallel, one joint
meeting the 2nd day.
fantasai: People prepare topics for the F2F. Let's do those topics
first, then split into parallel for the rest.
Florian: 3 days is not long. 7 days is long.
Florian: There's no need to shorten a 3 day meeting. We can have
Houdini in parallel with some CSS topic.
TabAtkins: With few exceptions (fantasai :-) ), half of room tunes
out for some topics.
Rossen: We can try maybe already in Sydney.
johannes: page-related stuff can also be split out in parallel.
dino: So that means we need multiple rooms.
TabAtkins: One big room and some small.
shane: I can't guarantee extra rooms in Sydney.
johannes: There may also be even "smaller" topics, say footnotes.
rossen: I will send out a mail, list the topics, and ask people
what they want to work on.
rossen: Be honest: if you don't care about X, that's OK
astearns: You mean break-outs will never resolve on anything?
rossen: They will resolve, but report.
rossen: We have two chairs, we can have two parallel sessions.
stevez: I think fantasai's point is that there are resolutions,
but people not there can come back to them.
florian: Better to call it a tentative resolution.
florian: Then you can reopen, even if you bring no new arguments.
rossen: OK, we'll try to start this method in Sydney, if we can
get rooms.
shane: We can't get rooms on Monday, maybe on other days.
rossen: That'll work.
fantasai: If we split ourselves too much, CSS gests inconsistent,
so,
fantasai: I'm in favor of coming to resolution, but indeed call it
tentative. Want to encourage everyone to be engaged in
the topics even if they weren't present in the breakout.
[Adjourned until tomorrow]
Received on Thursday, 19 November 2015 01:39:38 UTC