- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 10 Jul 2013 15:33:16 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- Discussed whether to require use of width-specific glyph variants in TCY
- RESOLVED: Accepted dbaron's proposal for MQ white space erratum
- RESOLVED: Whomever updates errata doc, must send update message to www-style.
- RESOLVED: Define CORS stuff for shapes in Shapes
- RESOLVED: Agreed to start drafting Shapes Level 2 as ED
- RESOLVED: Grid auto-positioning uses sparse (sequential) packing
- Discussed proposal for new mask shorthanding scheme
http://lists.w3.org/Archives/Public/www-style/2013Jun/0645.html
and problems of back-compat with SVG mask references
- Discussed background clipping area for background-attachment: local; general
agreement to make it relative to scrollable area, will revisit next week.
====== Full minutes below ======
Present:
Glenn Adams
Rossen Atanassov
Shezan Baig
David Baron
John Daggett
Justin Erenkrantz
Elika Etemad
Simon Fraser
Sylvain Galineau
Daniel Glazman
Rebecca Hauck
Koji Ishii
Brad Kemper
Philippe Le Hégaret
Chris Palmer
Anton Prowse
Matt Rakow
Florian Rivoal
Dirk Schulze
SImon Spin
Alan Stearns
Lea Verou
Steve Zilles
<RRSAgent> logging to http://www.w3.org/2013/07/10-css-irc
ScribeNick: fantasai
Administrative
--------------
glazou: Justin suggested to host first 2014 F2F in NYC
glazou: Right time to start looking for hosts. Not going to resolve now,
but getting options would be cool.
glazou: That said, extra items?
Writing Modes: TCY
------------------
<glazou> http://lists.w3.org/Archives/Public/www-style/2013Jul/0111.html
jdaggett: Last week there was a resolution about the algorithm
jdaggett: which left the decision to use width-specific variants up to the UA
<jdaggett> http://lists.w3.org/Archives/Public/www-archive/2013Jul/0011.html
<jdaggett> http://lists.w3.org/Archives/Public/www-archive/2013Jul/0014.html
jdaggett: A UA could simply do scaling, or use width variants as it saw fit
jdaggett: Posted some examples
jdaggett: Example of 107
jdaggett: showing scaling vs. variants
jdaggett: This is imporant because font designer put this into the font
jdaggett: UA shouldn't be synthesizing things
jdaggett: UA should be required to use the variants
jdaggett: Arguments about cases where other behaviors might be better
jdaggett: Based purely on scaling, will produce different results based
on width of glyphs
jdaggett: See, e.g. second URL
jdaggett: alphabetic text
jdaggett: case 5, scaling only
jdaggett: IA looks normal, but MM looks much lighter
jdaggett: It will make a difference in readability
jdaggett: Whereas case 4 has the right weight
jdaggett: This is already what implementations are doing
jdaggett: Would like this to be the required behavior, so we can actually
test it
fantasai: We can test things that aren't required.
fantasai: We do this in other places
<stearns> given http://lists.w3.org/Archives/Public/www-style/2013Jul/0179.html,
I'm assuming we should require width variant glyphs when all
the glyphs have variants, but allow UAs to do what they want
when the TCY run has glyphs with no variants available
florian: Case of #12, some glyphs have variant and some don't
florian: Think we should say this case is undefined
florian: Do we all agree on this?
jdaggett: I'm fine to say, use width variants if all characters have width
variants
rossen: I agree with jdaggett. When we implemented text-combine-horizontal,
we assumed that if the font provides glyphs, then we should use those
rossen: And not create a crappy-looking solution just because we can do
it cheaper
rossen: Have a question, when we are going to require that we use the
font variants
rossen: Are we talking about digits, or regardless of which
text-combine-horizontal we're using?
rossen: e.g. case of text-combine: all, only 3 characters
rossen: would we also consider those?
fantasai: Considering any case
<fantasai> http://dev.w3.org/csswg/css-writing-modes/#text-combine-horizontal
<fantasai> Current text, fwiw (based on last week's resolution):
The UA must ensure that the combined advance width of the composition
fits within 1em by compressing the combined text if necessary. (This
does not necessarily mean that the glyphs will fit within 1em, as some
glyphs are designed to draw outside their geometric boundaries.) The
UA may use any means to do so, including substituting half-width,
third-width, and/or quarter-width glyphs provided by the font or using
other font features designed to compress text horizontally.
florian: jdaggett made case that if font designer made glyphs available,
should use them
florian: Question, are these glyphs designed only for TCY?
florian: There was also the case that these glyphs force monospace design
florian: But in some cases proportional width might be better
florian: Here we are not explicitly asking for half-width, you're asking
for TCY
florian: Easy to see these two things are related, but not necessarily
1-1 mapping
[some amount of argument over Florian's question]
florian: If these glyphs are only designed for TCY, better case that
they are the best thing to use
<SteveZ> For example I have, in the past, seen IBM in tate-chu-yoko
jdaggett: twid and qwid, definitely only for TCY. half-width, I don't know
<sgalineau> even assuming the 1/n glyphs were not designed with TCY in
mind the UA has no way to tell. Only the author can.
<stearns> can we resolve on using the variants when all the glyphs in
the TCY run have variants available?
jdaggett: If you scale based on width of 2-char proportional span, this
will result in variations in scaling factor
jdaggett: which gives poor readability
koji: I think you misunderstood what fantasai said
koji: Both she and I agree that width variants is better than scaling
koji: But sometimes you don't have to scale at all, and that's even
better than half-width variants.
jdaggett: That seems like a case where difference between half-width
variants and proportional glyphs will be very minor
jdaggett: Very minor
koji: Not very minor
glazou: We're far beyond 10min limit
jdaggett: I think we need more examples from ppl arguing against this
<fantasai> I suggest A' as an example where hwid would not be good
<SteveZ> A different view: the problem is the requirement that the result
fit into 1 EM; the Adobe folks (with Japanese typography experience)
that I consulted said the tate-chu-yoko should be as wide as is
needed and not affect line-spacing
Media Queries
-------------
Topic: White space in media queries
<glazou> http://lists.w3.org/Archives/Public/www-style/2013Jul/0130.html
glazou: Saw answer from dbaron on ML
florian: What we resolved awhile ago was that there are differences in
the WS handling of MQ and @supports
florian: @supports requires space between ')', 'and'
florian: We decided to make this the same
florian: Missed on some subtleties
florian: One is that, unlike @supports, not everything is between parens
florian: e.g. @media screen and (min-width: ...)
florian: Currently we don't require a space between 'screen' and 'and'.
You could put a comment instead of a space to separate them.
florian: To make things clean, suggest just requiring space there.
florian: Also @supports not ... requires space after not, MQ doesn't...
florian: Proposal is to harmonize all that
florian: by requiring spaces
florian: I proposed a new grammar; dbaron proposed a better grammar
florian: Suggest we go with what he said
<SimonSapin> +1, ship it
fantasai: I'm in favor
<bkardell> +1
glazou: me too
<dbaron> +1
glazou: No objection?
RESOLVED: Accepted
Reviewing Errata
----------------
dbaron: Another comment --
dbaron: I think errata need more review
<SimonSapin> +1 dbaron
dbaron: I think there have been errata posted to more than one of our
specs that don't match our resolutions.
dbaron: They should be announced to www-style for review by the person
updating the errata document.
plh: I think would be easy for whoever updated errata doc to do that.
RESOLVED: Whomever updates errata doc, must send update message to www-style.
Publishing
----------
jdaggett: Quick question...
jdaggett: There was a request to publish LC of Fonts. Is anyone going to
do it?
jdaggett: There was a request to publish... and no response from anybody
plh: I'll check; currently transitioning webmasters
plh: I'll double-check on that.
Shapes
------
topic: Cross-origin style sheets
glazou: Anyone able to handle that? No one from Opera?
topic: Shapes
<glazou> http://lists.w3.org/Archives/Public/www-style/2013Jun/0096.html
stearns: Where to define how to allow images from other origins in a
stable way
stearns: My understanding is that we need to define a [..] mechanism
where you pass a CORS flag and get a response that [..]
stearns: I can define this in Shapes, specifically
stearns: Or we can put it in CSS images, for the image type in general
stearns: I think that's really the only question -- where should it be
defined?
rossen: I don't care that this is part of Shapes
stearns: Any other opinions?
stearns: I'll put it into Shapes
fantasai: If we need to factor it out later, we can do that later
RESOLVED: Define CORS stuff for shapes in Shapes
<glazou> http://lists.w3.org/Archives/Public/www-style/2013Jun/0514.html
stearns: People in SVG want to point to some future CSS work for what
they want to do
stearns: particularly wrt shape-inside
stearns: though not on anyone's plate to do that right atm
stearns: Proposed to take what's on the wiki page, make a Shapes Level
2 draft
glazou: No problem with that
glazou: Most of what you added was already in the L1 drafts. Not as if
we never agreed to work on that. So in favor
glazou: other opinions?
* fantasai no objection
RESOLVED: Shapes L2 ED agreed
Grid Layout
-----------
topic: Grid Auto-placement Algorithm
<stearns> http://dev.w3.org/csswg/css-grid/#auto-placement-algo
<glazou> yes, sorry, bad url
Issue 17
This algorithm creates a "sparse" packing, where holes left behind are
never filled in. This is more efficient and predictable (items never
move to a position far above/before their preceding sibling), but the
gaps are unwanted by authors in some situations. We should have a
switch to allow for dense packing. (WebKit's current implementation
does dense packing.)
fantasai: Two ways to do auto-placement
fantasai: Sparse packing... you start in the 1, 1 slot
fantasai: and then place the next item that fits
fantasai: move to the next empty slot, and put the next item
fantasai: If something doesn't fit you keep moving until you find an
empty slot that's big enough
Scribe: dbaron
Rossen: how do you define "fit"?
fantasai: the span -- the number of cells
fantasai: Suppose you have 3 columns, and an item that is a 1x1, and
then you place another item that's 1x1. Then if you have an
item that's 2x2, you move to the next row and leave an empty
slot in the first row.
fantasai: (etc.)
fantasai: so you leave behind a bunch of holes
Rossen: so it doesn't fit based on the number of columns, not based on
sizing properties?
fantasai: right
fantasai: That's the sparse packing option. Advantage of it is that
things are in the order they appear.
fantasai: Other option is dense packing, which says you go back
fantasai: If you have a 1x1 empty slot on the first row that you skipped
because there's a 2x2 item, you go back and fill that hole.
fantasai: Advantage is no holes, disadvantage is that things get out
of order.
fantasai: When we discussed at Microsoft, thought it made more sense
to do sparse packing, at least for this level.
fantasai: Sparse packing is simpler, and don't get unexpected out-of-order.
fantasai: We have the option of adding a way to turn on dense packing in a later level.
<bkardell> I like the idea of dense packing as an option later
fantasai: I think this is the best thing to do; don't get unexpected
results, and dense packing would be an opt-in (ok to go out
of order).
<stearns> +1 to default to sparse, with an optional switch for dense
bradk: would that be based on the 'order' property?
bradk: ???
fantasai: Yeah, the order used is the order-modified document order.
?: what's default of 'order'?
fantasai: 0
* fantasai has a proposal in her inbox from florian to call 'order'
'visual-order' and wishes we'd gone with that, since it
makes it clear it doesn't affect speech/DOM :/
bradk: order is for the ???, not for the ??? itself, right?
fantasai: couldn't hear
bradk: was just saying that if ... then it would be sparsely packed,
otherwise densely packed
stearns: <missed>
bradk: but you could have order be something that overrides the dense packing
<bkardell> grid-visual-order?
stearns: I don't think this should be related.
stearns: order property just changes the dom order and that's the only
effect it should have on the packing algorithm
Rossen: Think of order as a pre-order .... reordering the elements.
Before layout.
bradk: could imply the author's intent to keep them in that order
Rossen: they are being kept in that order
bradk: ok, then. I don't feel strongly.
Rossen: <inaudible about not being able to ... examples>
Rossen: From impl pov ...; but definitely easier to explain.
Rossen: ... float layout... position float, if not enough space, push
below until find space. You never backtrack.
Rossen: So sparse ordering or auto ordering will ... that, dense will
be fancier in terms of implementation but not sure it's more
intuitive for users.
* stearns agrees that dense packing is like a more complicated float stacking
Rossen: so should we go with sparse?
bradk: I don't feel strongly.
glazou: I think we should.
RESOLVED: sparse packing for grid auto position
mask shorthand
--------------
<glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2013AprJun/0287.html
<krit> http://dev.w3.org/fxtf/masking/
<krit> http://dev.w3.org/fxtf/masking/#box-image-masks
krit: shorthand is bad
krit: request from fantasai about making one mask property that turns
off all masking
krit: fantasai wanted mask to reset mask-box-image etc.
Scribe: fantasai
krit: fantasai requested that 'mask' also reset 'mask-image' and related
properties
krit: Request led to new design for mask properties
krit: where 'mask' would be overall shorthand for all masking properties
krit: here's a link for how it could look like
<krit> http://lists.w3.org/Archives/Public/www-style/2013Jun/0645.html
krit: we would have mask-layers, which would be like 'background' shorthand
krit: and we would have mask-element, which does svg references
krit: and then mask-box, like box-image
krit: seem to have agreement on overall structure
krit: question is, what is the shorthand able to set?
krit: shorthand similar to 'border' shorthand -- resets all border
properties including border-image, but not able to set border-image
explicitly
krit: My proposal is to have 'mask' only set mask-element
krit: It already does that
krit: and it's hard to distinguish URLs for different things, so hard
to add in anything other than mask-element reference
smfr: So, you're saying if you use 'mask' shorthand, can't set both
mask-box and mask-layers?
smfr: So you have mutually-exclusive options in a shorthand... which
is confusing to me
florian: It does happen, not that rarely, that you can do basic things
in shorthand and other things need to go to longhand
krit: fantasai would like to also allow mask-box / mask-layers into shorthand
krit: but this leads to parsing problems, because url() is ambiguous
smfr: Sounds like it would be a very confusing shorthand
krit: Problem is really that these all use url() function
krit: Need to distinguish which property you want to assign the url()
to at parse time
krit: One idea was to check for fragID, assume it's an element
krit: But request that we don't do that
florian: No, that doesn't seem pretty
smfr: So saying mask-layers is not part of shorthand at all?
smfr: But can reset the masks with the shorthand?
florian: shorthand can only set 'none'
smfr: So confusing
smfr: properties interact in non-symmetrical ways
<SimonSapin> 'border' also resets 'border-image' but can not set it
krit: mask-layers is already a shorthand
smfr: I think this adds too much confusion for something that won't be
used very often
krit: Even without this, still kindof hacky
krit: because of 'mask' setting SVG masks right now
florian: This doesn't bother me much
glazou: Opinions here? smfr thinks undesirable?
smfr: Think it's too much complexity to get one part of behavior
florian: I'm ok with it
krit: If we don't do this, we still need a way to distinguish mask element
and mask layers
bkardell: Is this just about having top-level shorthand support
none | <mask-element> ?
smfr: mask-element is the svg-style one
smfr: not represented in WebKit prefixed version
smfr: Which are possibly used more often than SVG one
krit: Might be right
glazou: What should we do now?
krit: 'mask: <mask-element> | none' is part of SVG REC
bkardell: if I understand correctly, question is, either there is no
mask shorthand directly
bkardell: Or, is it this limitation of mask-element || none?
krit: We have this mask property already, which points to SVG. So either
way, we need a way to handle this back-compat situation
bkardell: I like ability to say 'none' at the shorthand level
florian: I really don't like parse-the-url thing
florian: Everything else so far, I'm comfortable with, but that I'd like
to avoid
* fantasai too
krit: I don't think smfr's proposal is possible.
smfr: Just have 3 separate properties
<bkardell> not possible even if it can only do none?
krit: mask-element will have to be called just 'mask', then
krit: because we already have this property in spec + implementations
[basically, 'mask: none | <uri>' has to work somehow ]
fantasai: I guess one thing to think about is, is there anything we can
do to the syntax in the shorthand that would let us distinguish
the longhands in it?
CSS3 Backgrounds
----------------
Topic: painting area & background-attachment: local
<glazou> http://lists.w3.org/Archives/Public/www-style/2013Jun/0276.html
SimonSapin: Decided recently, positioning area of
background-attachment: local is the scrolling area
SimonSapin: Think it should be the same for the clipping area
SimonSapin: If we consider the background is inside the scroll box
SimonSapin: It should also keep the same as the content, that is the
padding box
SimonSapin: So intersection of rectangle based on background property
and clipping property
glazou: Opinions?
smfr: What is the visible difference?
SimonSapin: Mostly when you have bg-clip: content-box; and some padding
SimonSapin: You have some area that has no background at the top, but
when you scroll that area disappears
SimonSapin: but if you consider that the clipping area is not scrolling,
then you always have this padding not scrolling as well
smfr: I think I understand, but would love testcases / diagrams
fantasai: I totally agree with this, it is obviously the right thing to do
<glazou> +1
<bkardell> looks good to me
smfr: seems you'd use different clipping for different bg layers based
on whether local or not
smfr: Would make implementations a little more complex
SimonSapin: Possibly
SimonSapin: Currently working on patch for that in Gecko. Not a problem
for us, though might depend on architecture
glazou: Anyone objecting?
<bradk> Should it also depend on presence of scrollbars?
smfr: I would like diagrams
glazou: OK, revisit next week
<SimonSapin> smfr, the diagrams should be the same as for the positioning
area
<SimonSapin> but I could make more with padding and border-radius, if that
helps
<SimonSapin> http://lists.w3.org/Archives/Public/www-style/2013May/0542.html
<smfr> I'm a bit worried about implementation complexity
glazou: And we have 1 minute on the call... anything else for 1 minute?
Meeting closed.
Received on Wednesday, 10 July 2013 22:33:51 UTC