- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 14 Jan 2015 20:57:22 -0500
- To: www-style@w3.org
Counter Styles
--------------
- RESOLVED: Add Tamil back to Counter Styles spec
Flexbox
-------
- The discussion of 'order' affecting tab order and speech order
will wait until Bo Campbell is on the call.
Grid Layout Issues
------------------
- RESOLVED: Re-add the mandatory minimum of 1 million tracks
- RESOLVED: Drop the "stack" value from Grid
- RESOLVED: Allow "auto" in minmax(), have it look at
min-width/height for value, using same "auto" behavior
as flexbox
- RESOLVED: Accept repeat(auto, ...) syntax
- Deferring on a decision about justifying grid tracks to give a
chance to consider the implications
unprefixing min/max-content keywords
------------------------------------
- RESOLVED: Unprefix min/max-content keywords
:lang() Issues
--------------
- RESOLVED: Require quoting :lang() values as a string if they
have asterisks.
'direction' propagation from <body>
-----------------------------------
- There was some concerns about the implications of this change,
but due to the limited amount of time remaining on the call,
nothing was resolved or decided.
===== FULL MINUTES BELOW ======
Present:
Rossen Atanassov
Tab Atkins
David Baron
Bert Bos
Adenilson Cavalcanti
Tantek Çelik
Alex Critchfield
Elika Etemad
Sylvain Galineau
Daniel Glazman
Toru Kawakubo
Brad Kemper
Chris Lilley
Peter Linss
Shinyu Murakami
Simon Pieters
Florian Rivoal
Simon Sapin
Ian Vollick
Greg Whitworth
Steve Zilles
Regrets:
Bo Campbell
Dave Cramer
Simon Fraser
Dael Jackson
Brian Kardell
Michael Miller
Anton Prowse
Dirk Schulze
Mike Sherov
Lea Verou
Scribe: fantasai
plinss: Anything to add to agenda?
fantasai: Tamil list numbering?
plinss: No.
fantasai: K, let's do that one first. Should be quick.
plinss: Please suggest items for CSSWG / Project Houdini agendas
Counter Styles
--------------
TabAtkins: Recently it was pointed out that when we added counter
styles for Indian languages, added 8/9 Indian numbering
TabAtkins: Seems like an unintentional slight.
TabAtkins: Tamil is the missing one; implemented by only one
browser, Firefox,
TabAtkins: Which is why we left it out,
TabAtkins: But I think we should add it in for completeness, and
not unintentionally slighting anyone.
Florian: I'm usually in favor of trimming specs down, but this
seems perfectly valid reason to add it.
bradk: What about exit criteria?
TabAtkins: It's not yet implemented by two, but adding a new
counter style is very quick
bradk: In that case, I have no objection.
plinss: Any objections?
RESOLVED: Add Tamil back to Counter Styles spec
<dbaron> We also have a resolution to go to CR from about a year
before.
<fantasai> Yeah, but that one kindof got overtaken by xidorn's
long list of issues.
<dbaron> ... which were the result of implementation experience...
fantasai: Hang on, for counter styles, we have a resolution from
last month to go to CR
fantasai: Is that in progress, or fell off of the to-do list?
ChrisL: No idea
ChrisL: Will look at it
<ChrisL> I see
https://lists.w3.org/Archives/Public/www-style/2014Nov/0511.html
where tab says "Yeah, I'm supposed to publish it as CR.
Just haven't gotten around to it yet."
<fantasai> ChrisL,
http://lists.w3.org/Archives/Public/www-style/2014Dec/0298.html
<fantasai> ChrisL,
http://www.w3.org/mid/CAAWBYDBaGNm+OK+6Rzf7Ko64k+V2jp_qWzt8Vzr+jUOVibXbZw@mail.gmail.com
<ChrisL> fantasai, and the disposition of comments is where? was a
transition request ever sent?
<fantasai> ChrisL,
http://www.w3.org/mid/CAAWBYDB4DcJJqnCTNZOPCkZQdjK2Hi1=iO_Ed-Rc4jtrd68AUw@mail.gmail.com
http://www.w3.org/mid/CAAWBYDA858yqtdFFDdMQ=Gcg5WTyyQK=GnHMwPUVvi2Y0XA0vA@mail.gmail.com
<fantasai> ChrisL, no idea about transition requests. The editor
sent a request to transition (disguised as a request to
publish, but still)
Flexbox
-------
<Florian> http://www.w3.org/mid/CAAWBYDAoGDQGZ9J42nA2zHNWMjJ5WfxDQ=XbuvqBSyM-P4geog@mail.gmail.com
Florian: A request raised again about 'order' affecting tab order
and speech order.
Florian: It was pointed out that there was a reason for this
difference,
Florian: And we pushed back to ML/wiki
Florian: There was an answer there, but it doesn't really address
the reasoning presented for how it currently works.
Florian: So, we're not really making progress...
TabAtkins: I'm still of the same opinion of the WG, that the spec
is right as-is.
Florian: I agree. They may have a point, but not really making it.
Rossen: I'm on the same page as well.
plinss: We should come back to it when Bo Campbell is around.
Rossen: Will this hold the spec back? We're trying to get the spec
back to CR soon.
fantasai: I think it's important to get all the other fixes
published.
fantasai: I'd prefer to publish and take this up as an issue
against the new CR.
Rossen: I don't want to hold publication hostage to this issue.
Scribe: TabAtkins
plinss: How close to publication?
fantasai: Just need to finish up DoC and cross-check.
plinss: Ok. We'll come back to this issue with Bo on the call.
Grid Layout Issues
------------------
<plinss> http://lists.w3.org/Archives/Public/www-style/2015Jan/0168.html
fantasai: Tab and I went through all the issues and made a bunch
of fixes and such. We need to get WG approval.
fantasai: First is about clamping overlarge grids.
fantasai: We needed to add a section for what to do if you can't
handle a gigantic grid.
fantasai: The rule we came up with is that the start and end
edges, whichever is outside the bounds, gets shoved back
into the grid in the last possible position, while
maintaining a span of at least one.
fantasai: So if you're totally outside the grid, your span gets
truncated to 1 and you're shoved inside. If you're just
partially outside, the dangling side gets shoved inside
{shrinking your span).
<fantasai> http://dev.w3.org/csswg/css-grid/#overlarge-grids
fantasai: One wrinkle, if you have a huge grid due to a huge
repeat(), should you stop the repetition on a whole
number of repeats, or just let it stop when you hit the
limit, even if it means only a partially-completed
repetition at the end.
plinss: The text seems fine. It looks like there's no recommended
minimum?
TabAtkins: I previously had text giving a recommended minimum of 1
million tracks. Looks like that was removed.
fantasai: I don't think it was really intentional.
Rossen: Let's just add it back; it'll make the feature more
testable.
Rossen: I think I remember something in Flexbox limiting something
to two bytes?
RESOLVED: Re-add the mandatory minimum of 1 million tracks
fantasai: Next issue is dropping the "stack" value.
fantasai: It's not a great value. We think we should just drop it.
MS will need a value that puts things in slot 1,1 anyway
(which doesn't match "stack" behavior), so they can just
keep an MS-specific value for that in their UA
stylesheet.
RESOLVED: Drop the "stack" value from Grid
fantasai: Next is about minimum size of grid tracks.
fantasai: In the Grid spec, if you have an auto or flex-sized
track, you use the largest of the min-contents of the
things in the track as the "minimum size" of the track,
and then grow it or flex it from there.
fantasai: This doesn't work well for items that have a specified
minimum size.
fantasai: We have a min-*:auto value from Flexbox. The idea is to
have Grid behave the same way.
fantasai: Default behavior would stay the same, due to "auto", but
let people override.
fantasai: This allows "auto" in minmax() - minmax(auto, foo) means
"use the specified min-* property value", and that
"auto" on its own expands to "minmax(auto, auto)".
plinss: Seems fine, but it look like there's a few subtleties I
haven't wrapped my head around.
fantasai: I had Peter Salas look over the algorithm, and made some
fixes. I think the algorithm ends up fine.
plinss: Any implementors have any opinions?
Rossen: We were part of the discussion, and were fine with it.
RESOLVED: Allow "auto" in minmax(), have it look at
min-width/height for value, using same "auto" behavior
as flexbox
fantasai: One issue in many grid systems is to allow as many
columns as there is space.
fantasai: But right now repeat() only allows a fixed number of
repetitions.
fantasai: We propose adding repeat(auto, ...) to solve this case.
TabAtkins: For example, a catalog display that auto-flows things
into a grid; each item is 200px, but you don't know how
many columns that would end up using.
fantasai: And it is easy to calculate, because things are fixed-
size.
plinss: Makes sense.
plinss: One thing that might make sense is [missed].
TabAtkins: Send an email with an example?
<gregwhitworth> yeah an email would be nice
plinss: Having one auto-sized track, and then filling the rest of
the grid with auto-counted track,
plinss: Number of auto-counted tracks would depend on the width of
first track,
plinss: But maybe it's too complex for now.
RESOLVED: Accept repeat(auto, ...) syntax
fantasai: Next is justifying grid tracks.
fantasai: An implementor brought up application of 'stretch' and
'space-between'/etc in Flexbox, and whether they apply
to Grid.
fantasai: In Grid we originally treated the entire grid as a fixed
box that got centered or whatever, but it was pointed
out that it's useful to be able to justify the tracks.
fantasai: So if you have X tracks taking up *almost* the
container's width, it's useful to fill the leftover
space between the tracks.
fantasai: So we changed the spec to make the individual tracks be
the alignment subjects.
fantasai: The "line" separating tracks can have "thickness",
sorta, with the distribution values.
fantasai: For "stretch", you add a little bit more space to all
the tracks at the end, similar to Flexbox.
plinss: I'm okay as long as this isn't the default behavior.
fantasai: It's not.
plinss: Also, how does this interact with gutters?
fantasai: Specified gutters would end up being a minimum
separation between tracks.
fantasai: You run the grid sizing algorithm to find the size of
the grid tracks, then increase the size of the tracks to
handle stretch. This gives you the final grid areas into
which you lay out the grid items
<fantasai> Actually, we might need to clarify that point :)
Rossen: Can we defer resolving this? I'd like more time to think
about it.
fantasai: You were on the call when we discussed it in December,
but sure, if you need more time.
unprefixing min/max-content keywords
------------------------------------
fantasai: We've got this Sizing spec which needs a good bit of
work yet to get fully stable; there's a lot of
complicated sizing stuff that's not very well-reviewed,
with some parts missing, etc.
fantasai: It'll take a while to get a lot of the definitions
stable and correct.
fantasai: But the syntax of min/max-content keywords and what they
mean is stable.
fantasai: The Grid Layout spec is also using these keywords in
grid-template-rows/columns, so once Grid advances a bit
we can't change them anyway.
fantasai: And min/max-content concepts show up in the engines
already (despite some occasional inconsistencies).
fantasai: So the keywords are super-useful. It would be nice if
people could use them. So since we know roughly what
they mean, and we're already exposing their potential
incompatibilities through layout, we should go ahead and
unprefix them now.
fantasai: Or possibly wait until Grid goes to CR to unprefix them.
dbaron: I'm not sure the definitions in the block direction work
in all contexts.
fantasai: Yeah, I'm unsure what the correct answers always are in
the block dimension. In the inline dimensions it's very
clear what they mean.
dbaron: I think they depend on layout, and I think there are some
things that depend on them not depending on layout.
TabAtkins: height:min-content is basically just "the height after
layout".
Rossen: Yeah, height always depends on width in block layout. That
shouldn't be anything new.
Rossen: I think we had this discussion in the past, and it was
mostly related to orthogonal flows, and what min/max-
content mean in that context.
Rossen: We can't get around having some layout dependency for the
cross dimension, in logical terms, but the main dimension
should always be independent of layout.
Rossen: So are you currently concerned with them being unprefixed?
TabAtkins: Well, Firefox doesn't implement the keywords for
'height' right now.
dbaron: I'm a little worried about them ending up as something
that makes sense in Flexbox and Grid and doesn't make
sense in Block, in the height dimension, but I guess I'm
okay with unprefixing them. Though I don't think the block
dimension will be very interoperable for a while.
fantasai: Yeah, if we could unprefix them for just the inline
dimension, we would, but that's effectively impossible.
We could put a warning in the spec that says that using
it in the block axis might be unstable. Most people will
use it in the inline dimension anyway.
plinss: I'm a little concerned about having them defined in a spec
that won't be ready for years.
fantasai: Well, the entire point of this spec is to define these
keywords, moving it around won't help.
fantasai: The issue is the complexity in intrinsic sizing in a
bunch of edge cases. Table layout is mostly complicated
due to intrinsic sizing.
RESOLVED: Unprefix min/max-content keywords
:lang() Issues
--------------
<TabAtkins> https://lists.w3.org/Archives/Public/www-style/2014Dec/0177.html
TabAtkins: Previously we resolved to allow asterisks in :lang(),
but per my email (above) I think we shouldn't. The
legacy language behavior for ident-ish things can stay,
but as soon as you need an asterisk, which breaks ident
parsing, we should require use of strings.
TabAtkins: In general, terms defined from outside CSS are
represented with strings, as it avoids parsing
confusion.
fantasai: I think problems with asterisks is something that will
be very rare for authors to run into, but I don't have
objections if y'all have a strong opinion.
Florian: Mini-grammars not inside quotes tend to get painful
eventually (see recent issues with unicode range), so I'm
with tab
plinss: So, any objections to requiring string?
RESOLVED: Require quoting :lang() values as a string if they have
asterisks.
<SimonSapin> TabAtkins, so :lang() syntax is still `<ident> |
<string>`?
'direction' propagation from <body>
-----------------------------------
zcorpan: It seems that browsers are propagating 'direction' and
'writing-mode' always from <body>, even if it's set on
root element as well.
<zcorpan> https://codereview.chromium.org/758073003
zcorpan: So we should just specify the implemented reality.
<zcorpan> probably
fantasai: I wonder what happens when you make the <head> visible?
fantasai: Does it use the <body> direction/writing-mode?
dbaron: Gecko does different things in different places. There are
2 or 3 places in our code where we care about the
direction on the root, and they're inconsistent with each
other.
<zcorpan> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3366
- visible head, dir on body
Florian: In general, I think we should avoid making <body> special
unless there's compat.
fantasai: I want to keep writing-mode consistent with direction.
fantasai: I don't *mind* making them inconsistent, but...
fantasai: I think the important one to consider here is direction.
<zcorpan> in blink direction and writing-mode are consistent with
each other i think
<dbaron> for Gecko doing different things, see
https://bugzilla.mozilla.org/show_bug.cgi?id=1071098#c16
tantek: Does it affect the title element?
TabAtkins: Yes, the one on the page. I'm unsure what happens in
the browser tab.
TabAtkins: In Chrome, <title> in the tab doesn't pay attention to
rtl.
fantasai: What is the percentage of pages that have dir=rtl on the
body and not on html tag?
Rossen: You can have the same thing specified with properties.
fantasai: Yeah, but it's rare and bad practice.
Received on Thursday, 15 January 2015 01:57:49 UTC