- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 30 May 2012 17:21:27 -0400
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- RESOLVED: Support the publishing of Fullscreen provided the edits (in
minutes) are made.
- RESOLVED: Switch before/after logical directions to head/foot (globally,
across all of CSS)
- RESOLVED: Tab and fantasai to decide on directional keywords for alignment
====== Full minutes below ======
Present:
Glenn Adams
Rossen Atanassov
Tab Atkins
David Baron
Ryan Betts
Bert Bos
Tantek Çelik
Phil Cupp
Katie Ellison
Elika Etemad
Simon Fraser
Sylvain Galineau
Koji Ishii
John Jansen
Chris Lilley
Peter Linss
Alex Mogilevsky
Edward O'Connor
Florian Rivoal
Dirk Schulze
Alan Stearns
Steve Zilles
<RRSAgent> logging to http://www.w3.org/2012/05/30-css-irc
Scribe: TabAtkins
plinss: Any last minute agenda additions?
Fullscreen Spec
---------------
plinss: Webapps wants to publish a FPWD.
plinss: This is a joint deliverable with CSS, so we need to sign off on
it as well.
fantasai: There's a few minor things to fix up, but overall I think it's
fine.
ChrisL: I agree with some of the things that Daniel talked about, but
think it's okay to publish.
<glazou> http://www.w3.org/mid/4FC630E6.1050406@disruptive-innovations.com
ChrisL: We should probably triage between things that need to be addressed
before publishing and what can wait until after.
glazou: Main comments are #2 and #4.
glazou: I think the section about ::backdrop is unclear.
glazou: I think fantasai gave a good explanation of what it represents,
but it needs a better explanation in the spec.
glazou: Second thing is the definition of "layer". I think it's pretty
unclear.
glazou: For example, I don't know what "Layer 10" is.
* ChrisL hopes it goes to 11
fantasai: It's referring to Appendix E, the painting order layer.
<fantasai> http://www.w3.org/TR/CSS21/zindex.html#painting-order
glazou: Okay, so it needs refs and hyperlinks. It's not understandable
as it is.
glazou: Provided these clarifications are added, I'm okay with the document
being published.
<tantek> I can work with Anne to make the edits happen today
<fantasai> tantek, see also
http://lists.w3.org/Archives/Public/www-style/2012May/1131.html
<ChrisL> tantek, that is very helpful
florianr: Daniel, I'm surprised you're not calling for the WHATWG ref
to be fixed.
glazou: It's important, but it doesn't need to be fixed now, and it's
outside the scope for the CSSWG comments.
glazou: We'll make the comment and see if the consortium agrees later.
[missing some minuting about WHATWG ref]
TabAtkins: (doesn't see any reason to change the ref besides "We hate the
WHATWG")
sylvaing: Is there any reason it needs to point to WHATWG version? If not,
should point to W3C one.
<sylvaing> I don't see any reason to link to the WHATWG except 'we hate
the W3C' :)
Edits requested by CSSWG:
1. Update the ref to to W3C spec.
2. Update the text around ::backdrop to better explain what it's for.
3. Ref/link the talk about "Layer 10" and similar.
4. Fix computation of the 'position' property ('center' doesn't exist yet)
http://lists.w3.org/Archives/Public/www-style/2012May/1131.html
5. In the SotD, it needs to point to both WGs and say that it's explicitly
a joint product.
<tantek> the "Update the text around ::backdrop to better explain what
it's for" is a bit vague
<tantek> and seem so to require another review / re-evaluation before
proceeding
<glazou> tantek: for the time being, nothing is said about what _it is_
<TabAtkins> tantek: Suggestions welcome. That's roughly what Daniel's
feedback was.
<glazou> tantek: just say what it represents
<tantek> would an additional 1-2 sentence description be sufficient?
<ChrisL> +1 to publish with those edits
<glazou> what ChrisL said :)
RESOLVED: Support the publishing of Fullscreen provided the edits (in
minutes) are made.
florianr: What is happening with the future of this spec? Do we just
count on Tantek remembering to bring it by the WG sometimes?
<ChrisL> going forward we would expect to be more closely involved in
creating the actual text
ChrisL: I think we need closer involvement.
hober: How is this different than anything else?
<glenn> i am also a member of both groups
glazou: I think it's not difficult for tantek to just bring things by
sometimes.
plinss: As editor, Tantek has responsibility to bring updates to the WG
See Appendix A for Tantek's responses.
Alignment/Flexbox/Writing Modes Terminology and Naming
------------------------------------------------------
+tantek
+Rossen
Scribe: fantasai
fantasai: [discusses switching to head/foot instead of before/after]
<fantasai> http://wiki.csswg.org/topics/rename-before-after
fantasai: So far we haven't released any actual syntax using before/after
as keywords or properties.
<glenn> -0.9 on change to head/tail; don't believe before/after is confusing
alexmog: What makes this better?
<fantasai> http://lists.w3.org/Archives/Public/www-style/2012May/1065.html
TabAtkins: before/after has never been great, and ::before/::after is
obviously confusing with it.
<sylvaing> +1 on the confusion with ::before/::after
szilles: is head/foot culturally sensitive?
[...]
fantasai: There's two questions. We *must* have different keywords for
the two axes, for things like caption-side. Then there's the
question of whether the alignment properties should use those.
szilles: I think before/after is relatively clear [...]
<glenn> agree with alex
Tab: I have no experience with Japanese publishing, so don't know if
document headings are on the top or the side
Koji: Footnote appears on the left
fantasai: And a heading appears on the right side of a section
<ChrisL> so it is consistent between horizontal and vertical
alex: We haven't had time to think about this
alex: Regardless of what we decide here, my vote for Flexbox is to use
start/end in both dimensions
plinss: You want Flexbox to use start/end even if everything else switch
to head/foot?
TabAtkins: Recall that this is not just for Flexbox, for the alignment
properties that will be used for all layout models
discussion of Hamburg resolution to adopt box-alignment across layout models
dbaron: We didn't decide to use them for block yet.
Florian: I'm in favor of using the block-axis keywords in that axis,
regardless of what they are
Florian: Don't have a strong opinion on which keywords to use, but prefer
head/foot
some confusion over orthogonal flows
TabAtkins: We're only talking naming today, not layout concepts
szilles: I think you're missing Bert's point, [he's confused about ...]
szilles: Basically the coordinate system changes at the content edge
szilles: Outside the content edge, use the parent's coordinate system
szilles: inside the content edge, use the element's coordinate system
* fantasai suggests chairs call a straw poll
* ChrisL lets avoid 'rename all the things'
Bert: [describing some wording problems with logical terms]
TabAtkins: So you're saying head/foot is easier to do
Bert: Should just use A/B/C/D to refer to sides of the box
TabAtkins: No, that's horrible.
<glenn> -1
plinss: Is anyone objecting to switching to head/foot?
<sylvaing> is not hearing strong objections but is not hearing much of
a consensus either
<stearns> fwiw I like head/foot too
szilles: SVG uses text-before/text-after
fantasai explains that text-before isn't really the before side anyway,
it's the "over" side
ChrisL: SVG is happy to follow CSSWG
szilles: I can live with head/foot
* alexmog prefers before/after. not clear at all that head is logically
before.
Florian: I might be wrong, but I think it's the first time we use body
parts in a spec
<tantek> HTML has THEAD TBODY TFOOT
fantasai: HTML has <header> and <footer>
sylvaing: As far as English goes, it's a decent choice, and I think it's
much clearer.
RESOLVED: Switch before/after to head/foot
<tantek> Florian, CSS 2.1 uses table-header-group, table-footer-group
http://www.w3.org/TR/CSS21/tables.html#table-display
[See Appendix B for side-conversation]
http://wiki.csswg.org/topics/start-end-before-after-align
<glenn> would like different keywords for different axes
TabAtkins: My major objection to changing to 4 direction is that while
it makes sense for grid/block, which are writing-mode-relative,
TabAtkins: For flexbox, this isn't true
TabAtkins: So IMO using 4D for this particular set of property pairs would
be worse, and we should use start/end for both dimensions for
these sets of properties
TabAtkins: In the actual spec I use main-end/cross-end etc.
<glenn> but i agree with Tab on this
TabAtkins: Properties use just start/end because I didn't need to be more
specific than that.
[we're discussing the justify and align properties]
<glenn> can we use 2 keywords for flexbox, and 4 for grid/block?
Florian: So if we just have Flexbox and Grid, it's just a coin toss which
spec we're going to make more confusing
Florian: When it is the bock axis, it's going to be confusing that
start/end is used in block axis
fantasai: ... trying to establish start/end/head/foot as a flow-relative
set of directions, equivalent to top/left/bottom/right as
physical directions
fantasai: using start/end in both dimensions is inconsistent with that
...
Florian: These are logical dimensions, logical relative to what can
depend on layout mode
<glenn> initial/final?
TabAtkins: Referring to start side as head would be confusing
fantasai: Wouldn't referring to head side as start side also be confusing?
Phil: So, say I set margin-head: 10px; to put margin on head side of a
column flexbox, what do I set to bunch up the elements towards that
side of the box?
TabAtkins: Regardless of what we decide here, it would be
justify-content: start;
Straw Poll
A) use start/end/head/foot as flex-flow-relative instead of writing-mode-relative
B) use start/end/start/end in both dimensions
C) something else [TBD]
fantasai: A
* fantasai is ok with C as well
Florian: A
<florianr> A then C then B, to be specific
plinss: A
glenn: C
JohnJansen: abstain
Phil: abstain
smfr: abstain
rbetts: abstain
dbaron: abstain, though maybe A, but abstain
alex: B
TabAtkins: B
glazou: A
sylvaing: abstains
Katie: abstain
ChrisL: A
hober: abstain
szilles: B
stearns abstain
rossen: abstain
kojiishi: B
Bert: maybe B
tantek: abstain, unless consensus amongst editors
<Liam> [Liam fears head/foot will be confusing with respect to running heads
and footers, which are usually not writing-mode relative so B or C
if my vote counts :-) ]
<tantek> C = unicorns?
Options for C?
<glenn> by C I meant use something different for flow-relative
<rbetts> near/far?
<Rossen> Is C start/end/before/after
<fantasai> Rossen, no it's before/after/before/after
<fantasai> (or some other set of terms)
Florian: C is to use same terms for both, but not to use the flow-relative
directions
Rossen: So it's the same as B, except with different terms
<ChrisL> don't like the same terms to be used for both directions
* sylvaing recalls a time when renaming things made me understand them
better...
<glenn> I would vote A for grid/block, but don't like confusion that would
result if start/end also used with flexbox
<rbetts> if you don't use the same terms for both directions, then you'll
have to update two properties in concert. i.e.: if I change the
flex orientation then I'd have to update the justify and align
keywords, which seems unnecessary?
<fantasai> no, rbetts, the keywords are tied to the property, not to the
effective dimension
<rbetts> ah, ok.
plinss: Are people happy to use same terms in both dimensions?
fantasai: yes
<dbaron> I'll switch from abstain to A. :-)
Phil: I had resolution that we'd use fantasai's new alignment properties
for Flexbox
Phil: But her spec uses different terms in different dimensions
TabAtkins: This issue is about that spec
Florian: Because we're defining start/end to be in the inline direction,
I'm happy for either using head/foot in the other dimension, or
using a different set of keywords in both dimensions
fantasai: so where are we at?
fantasai: Are we going with C, if we can find a set of terms?
dbaron: I don't think we should have three sets of keywords because people
will have yet another set to confuse.
TabAtkins: I'm going to object to naming changes if we don't resolve this soon
<tantek> +1 to reducing namesmithing/thrashing/bikeshedding
<sylvaing> +100. bikeshedding at last call is an anti-pattern
Phil: Can we just prefix the flex alignment properties and fix this later?
<Ms2ger> That's an awful idea
fantasai: I don't think that is a good way of fixing the impasse
sylvaing: I don't like deciding on the API and then renaming the whole
thing, not an efficient way to work
<tantek> "rename all the things!" (or was that not to
)
sylvaing: But if we can just settle it now, let's do it. We can't keep
going like this.
florian: So we have all the preferences, but does anyone object to A or B or C?
apparently not
dbaron: I might object to C
<dbaron> The goal is that this stuff apply to more than just flexbox.
* Bert thinks 'justify-content: start' seems fine, but 'align-content: start'
is unclear: which side is that? Is that clockwise from the start of
the flexbox?
discussion of having fantasai and Tab work it out
RESOLVED: Tab and fantasai to decide on this issue
<glenn> i'm ok with fanasai/tab reaching mutual agreement
Meeting closed.
Appendix A:
<tantek> florianr - what do you mean by "bring it by the WG" ?
<tantek> you can just follow it on mercurial right?
<fantasai> tantek, I'm not going to watch your mecurial logs
<tantek> fantasai - not *my* logs - just the spec
<glazou> what fantasai said
<tantek> if you care about a particular spec, watch its mercurial
<glazou> tantek: no, you as editor, have responsibility to ping us
<tantek> no need to spam everyone with delta emails
<glazou> by _email_
<tantek> glazou , citation?
<glazou> re. mercurial
<tantek> is that a request for a mercurial to email bot?
<fantasai> no
<tantek> I am not a bot
<glazou> no, that's request to email us personnally
<glazou> from you, not bots
<fantasai> when there is something to discuss or review
<tantek> denied
<tantek> I am not going to email mercurial diffs
<fantasai> nobody is asking you to do that
glazou: If tantek isn't going to update the WG occasionally as appropriate,
I object to publishing.
<ChrisL> sigh, talk about snatching defeat from the jaws of victory
plinss: We'll take this offline. We won't resolve this with communicating
over IRC.
<tantek> are there any technical objections?
<tantek> or only bureaucratic?
* glazou urrrghhh
<florianr> non technical
<TabAtkins> tantek, you're being ridiculous. You know quite well that
we aren't asking for HG diffs on every update, just occasional
status updates like *every* editor gives for their specs.
<TabAtkins> Quit arguing badly.
<glazou> +1
<tantek> I'm sorry I forgot the cover sheet on my TPS report.
* ChrisL wants to know if the previous resolution still stands, given the
tantek 'denied' comment.
<tantek> ChrisL - I simply denied request for emailing HG diffs to the WG.
<TabAtkins> tantek: NOBODY ASKED FOR THAT.
<ChrisL> strawman
<sylvaing> tantek.mouth.insert(tantek.foot)
<glazou> tantek: just with ALL editors, we need to be kept posted when
important changes/additions are made
* tantek finds a phone
<tantek> glazou - I don't know how to evaluate what's "important" to
individuals. from my perspective, "important" changes should/will
trigger requests to publish an updated working draft, is that
sufficient?
<glazou> tantek: no
<sylvaing> tantek, glazou: can you guys hold on please?
Appendix B:
<tantek> regarding spec audiences, please see the spec restyling in effort
that fantasai, Vincent, and myself are working on :
http://www.w3.org/wiki/Restyle#Audiences
<sylvaing> tantek, very cool!
<tantek> Thanks sylvaing! To be clear - input is very much welcome.
<tantek> Feel free to even directly edit/add to the wiki page itself.
If we disagree we'll edit it further :)
<tantek> and likely ask to discuss it here.
<tantek> If there are disputed priorities/opinions etc., we'll try to
capture multiple viewpoints on the wiki.
Received on Wednesday, 30 May 2012 21:22:00 UTC