- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 15 May 2012 13:50:59 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Box Alignment
-------------
fantasai presented a proposal to converge all layout models on a single
set of alignment properties:
http://fantasai.inkedblade.net/style/specs/css3-align/
- RESOLVED: fantasai to continue working on this proposal
- RESOLVED: flexbox alignment properties to be replaced by css3-align
equivalents
Grid Layout
-----------
- RESOLVED: rename the values of grid-flow so that row adds rows, column
adds columns, and layer just stacks grid items on top of each
other.
- RESOLVED: add row-gap and column-gap to the specification such that they
provide uniform gutters
- Also discussed scoping of Grid Layout vs. Template, ways to remove
overlap, and scoping things for Level 1 vs. higher. No conclusions.
CSS3 Fonts
----------
- RESOLVED: fallback for font-variant-position occurs per run rather
than per-glyph
- RESOLVED: the 'font-variant-position' property is defined independent
of the existing use of the font-size/vertical-align properties
to synthesize subscripts/superscripts
- discussed small-caps fallback per-script rather than per-font,
and using text-transform rules for synthesizing small-caps
- noted proposed updates to prose for font-family syntax to match 2.1
errata
Spec Editing
------------
- vhardy showed off a tool to help editors synchronize specs with Bugzilla
- plinss explained plans to host test-annotated /TR specs
====== Full minutes below ======
Box Alignment
-------------
Scribe: sylvaing
<dbaron> http://fantasai.inkedblade.net/style/specs/css3-align/02
* Bert, seeing that we have failed to solve it in the past 12 years,
wonders if 30 minutes really will be enough. :-)
fantasai: the idea is to "align" all the CSS alignment properties and
resolve issues that have been put off for a long time
fantasai: CSS1 and 2 supported text-align, vertical align, auto margins
fantasai: new modules had many more alignment methods such as flexbox,
which has five alignment properties
fantasai: grid adds two properties
fantasai: this doesn't even cover vertical alignment in block layout
fantasai: and in order to support the alignment attributes in html,
more properties will be needed
fantasai: so the challenge is to come up with a set of common properties
that can be shared across modules
fantasai brings up the proposal
fantasai: there two axes of alignment
fantasai: the dimension affected: primary (inline/main) or secondary
(stacking/cross)
fantasai: and what is aligned: you'll either want to align the box within
its parent or align the content of the box within itself
fantasai: i tried to come up with a logical system to organize both axes
fantasai: the first part of the name defines what is getting aligned:
"box-", when the box aligns itself,
"content-" when its content is being aligned
fantasai: then "-justify" is in the inline axis and "-align" is in the
stacking axis e.g. box-align, box-justify
howcome: are these meant to be aliases?
fantasai: they would replace flexbox and grid properties, and add new
functionality to block and table alignment
howcome: if people use text-align?
fantasai: this is separate, none of these affect text-align
howcome: so text-align and content-justify do not overlap ?
dbaron, fantasai: content-justify align children
...
(discussing axis and checks in the overview table in the spec)
http://fantasai.inkedblade.net/style/specs/css3-align/02#overview
fantasi: box-align does not apply to blocks because a block can't control
its vertical position within its parent, it can only control its
horizontal position
(fantasai draws diagram on board; properties are set on red box)
http://lists.w3.org/Archives/Public/www-archive/2012May/att-0024/align-targets.jpg
fantasai: a grid item inside its grid cell can do both dimensions
fantasai: I map box-justify to grid-column-align and box-align to
grid-row-align
fantasai: if the inner element is a block, it can't control its own
alignment within its parent but it can control its box-justify
dbaron: so in inline layout justify controls the horizontal layout.
shouldn't -justify control vertical alignment for blocks?
fantasai: no, -justify controls the inline direction alignment
fantasai: justify is horizontal alignment, align is vertical (modulo
writing modes)
dbaron: I thought we should have only 4 properties out of these 6
dbaron: I think we could do without box-justify and items-justify
fantasai: no, because grid needs box-justify
fantasai: box-justify works in a manner similar to margins but adds
to margins
fantasai: the use-case for box-justify in blocks is wanting margins
in addition to alignment
fantasai: for example if I have a shrink-wrapped table, I want a 1em
margin around it but I also want the table centered
fantasai: but if the table fills its containing block I still want
1em between the table and its containing block
<Bert> (TeX-way to center: 'margin: 1em + 1fill')
dbaron: I thought this is what box-align did
fantasai: content-justify applies to the children of a block. it has
an auto value which, only on a block element, computes to
the value of its parent. this supports the HTML align
attribute which inherits
fantasai: content-align allows the children of a block to be centered
vertically
fantasai: it's like vertical-align for tables but applies across other
box types
fantasai: any value of content-align other than auto creates a BFC
vhardy: any value to automatically distribute space using content-align?
fantasai: we could add a distribute value
florian: since flexbox would depend on this, how do we move forward?
fantasai: we would rename all the relevant flex properties using these
names. we would define how they work for flexbox. for other
elements, they have no effect unless defined by another module
florian: we could keep the flexbox properties as they are. later we can
introduce the new ones and they would work as shorthand
expanding into the block align longhands. not sure whether
that would make them aliases on the OM side.
szilles: is it just a name change or is it a semantic change ?
fantasai: it's a name change for flexbox
szilles: I'm trying to distinguish their impact on flexbox vs. other
specs
szilles: if it's only a name change for flexbox this is very scoped.
whether we propagate this to other modules can be done at a
later time
florian: except these properties can be applied to other things today
and do nothing, then someday they'll do something
dbaron: I agree with both of you. the timeframe of this evolution
would have to be contained.
(fantasai draws pretty blue and red boxes on paper)
http://lists.w3.org/Archives/Public/www-archive/2012May/att-0024/align-flexbox.jpg
(multi-line flexbox with a number of items)
fantasai: the alignment of flexboxes is controlled by 5 properties
<sylvaing> if content-* applies inside and box-* applies outside,
should future display-inside/display-outside align their
name too?
fantasai: alignment of text to bottom inside red boxes is controlled
by content-align on red boxes
fantasai: alignment of red boxes within line is controlled by
box-align/flex-item-align on red box, whose auto value means
to default to item-align/flex-align on green box
fantasai: alignment/distribution of red boxes within line is controlled
by content-justify/flex-pack
szilles: there is an analogy between lines in flexbox and lines in text.
this model scales up the text behavior higher up.
dbaron: I think the axis make sense in this flexbox example. I'm not
sure I agree with the block example.
alexd: I think we should rename *-align with *-stack e.g. box-stack,
content-stack
fantasai: I'm not sure content-stack: baseline sounds right
<Bert> q+ to ask about mixture of 'box-align: bottom' and 'box-align: top'
on siblings.
howcome: I don't really understand how this applies to blocks. don't
you have to take it out of flow?
fantasai: no. you would make your content center vertically
fantasai: the entire content of a box has a particular height; if you
have leftover space you can align within that
bert: content-align aligns all the content. how do I align one child?
fantasai: how would you align only one child?
<dbaron> Bert's case is the reason I don't think we should have box-justify
and items-justify
bert explains his example: a 4-column layout, each column has some
images, text and color information at the bottom....
<Bert> http://www.w3.org/Talks/2012/0509-CSS-ftf/scan-12-small.jpg
fantasai: I think this is a case that should be handled using flexible
margins
florian: what are we resolving on?
fantasai: 1) whether we want to move towards a common alignment model
2) whether we want flexbox to be based on this proposal
szilles: I think we should move flexbox to this. this will also help
upcoming modules.
...
fantasai: I think you want both content-* and text-* properties since
you might want to align the blocks children and inline
children of a block differently
howcome: how does this interact with floats?
fantasai: I don't think it applies to floats
howcome: don't we want to look into this before moving this beyond flexbox?
szilles: we're no worse off with this names vs. the flex-* ones
szilles: these might generalize
florian: there is a risk that these properties will be applied using
'blanket' selectors and content will break in the future.
fantasai: I can work on this at a high priority
florian: we do not have content dependency for flexbox at least
vhardy: I think this is a great proposal. I agree it's high priority.
howcome: I think the start/before value names will confuse people
bert: most people don't need start/end/before/after
howcome: we should keep using top/right/bottom/left, this is what users
expect
plinss: can we resolve to keep working on this?
dbaron: I agree we should resolve to work on this
RESOLVED: fantasai to continue working on this proposal
fantasai: see Issue 2 about the naming model
RESOLVED: flexbox alignment properties to be replaced by css3-align
equivalents
<Bert> (Where I think "this proposal" means: an attempt to generalize
alignment across different box types, not necessarily with six
properties.)
florian: I'm happy with box and content
vhardy: I find the verb-what convention easier
vhardy: we got feedback on Regions/Exclusions that vert-object structure
was awkward in CSS
Grid Layout
-----------
Scribe: Shane Stephens
Present:
+Phil Cupp
+Daniel Holbert
+Markus Mielke
<fantasai> my issues list -
http://wiki.csswg.org/spec/css3-grid-layout#issues-for-hamburg-f2f
fantasai: I compiled a list after discussing with Microsoft
Scoping =
1. Scoping of Grid Layout and Template Layout specs
2. Drop named lines from this level of Grid Layout
3. Adopting column-gap etc., adding row equivalents, to handle gutters
fantasai: scoping principles we tried to apply were minimum set that
is useful for this level of grid
fantasai: to just reduce to as small a set as possible
fantasai: other principle was to just have coordinate based system and
leave others to a higher level
fantasai: more sophisticated addressing handled by template or level 2
of grid
fantasai: from those principles came suggestion: move template out of
grid and have bert keep in template spec
fantasai: drop named lines from this level of grid layout
fantasai: other issues on positioning things with negative indexes or
indexing from last line - push out as next level feature
fantasai: just focus on layout and positioning needed for layout
markus: didn't make sense to have template in both specs
markus: 2nd reason wanted to get more implementations faster
markus: got feedback from firefox about core aspects and want to reduce
to those aspects
markus: tried to reduce complexity for first version
phil: questioned whether or not the grid is suited to thinking about
content in tracks and position content by defining rectangular
area using start track and span length
phil: or instead talk about lines.
phil: conclusion was that you needed to talk about tracks in the spec
because all the styling functions are creating space for tracks
phil: but only need to talk about lines if lines are part of a
positioning scheme
phil: so it's easier to eliminate the concept of lines and just talk
about tracks
phil: think we can simplify all the language in the spec
tabatkins: and then later on name the tracks
plinss: I want to avoid that. The real power in grid is having the lines
phil: real power in grid is dividing the space afforded to the grid by
its parent
phil: whether you make use of the space by referring to four lines or
some tracks that intersect is a difference of perspective
phil: doesn't change functionality
plinss: I think it's a mental model shift. The way grids have been used
traditionally in page layout, designers don't think in terms of
tracks but in terms of lines.
plinss: page layout with grid - classic example: multiple columns, one
with sidebars and no text. The column next to that one - the
headings span out into the sidebar column.
plinss: the headings should be part of one flow in the middle track,
but certain elements snap to different grid lines so they
don't really live within a track.
phil: I totally agree they don't live within a track, but think of the
model - track has content structure. You define tracks and cells
with additional properties. In grid you can have overlapping cells
because the rectangular region is defined on the items. Free to
say you have a heading that spans into some center track and then
something else that intersects but doesn't occupy the same space.
phil: not in same container but share reference to same tracks (??)
phil: so I agree that tracks aren't containers, just spaces, and some
of the intersections of rows and columns can define a region for
positioning an item
phil: so the concepts are equivalent.
phil: Argument is that it'll be easier to read the spec if the mental
model is around tracks.
plinss: I agree that the shift in terminology isn't changing the features
plinss: my concern is the mental model. CSS is about cells and boxes,
grids gives you a different model. I don't want to lose that.
phil: Are you a fan of the spec as it reads now?
plinss: I haven't had a chance to look
markus: Feedback we got is that spec is confusing. Reading through it
introduces lots of models that do the same thing.
markus: Confusion: which should be used?
markus: We agree with your point. Lots of possible positioning models
that can live on grid. Absolute positioning. Templating.
markus: which is the fundamental concept and which can build on that?
phil: 4 positioning schemes in current spec: template, named line, using
numbers to denote start/end lines, using numbers to define starting
track and span length
phil: we want to boil that down to just 1
phil: because simpler is better
plinss: let's move on. I'll provide feedback over email.
stevez: 2 other things that lines give that change functionality:
(a) by using lines instead of numbers can add a line in the
middle of the grid and don't have to redo positioning.
Named lines give you more editing generality.
stevez: (b) using media queries can come up with different grids using
same named lines for different media - e.g. branch headings
out if there's enough space.
phil: One distinction - we're talking about the concept of lines as
numbers vs. tracks as numbers, not concept of named lines
phil: There's no difference between numbering systems. Doesn't apply
to named lines.
stevez: we are talking about named lines.
phil: your point: do we need some kind of indirection? Argument is one
of leveling - does it need to be in the first version of the grid
spec?
phil: not minimum level of functionality that provides usability
stevez: if you want to give users a good model for using grid, not
having naming schemes leads them down the wrong path.
plinss: if you want to avoid complexity, drop indexed system before
name-based system.
markus: we are seeing that it's easier for people to think in terms of
numbers right now, because of history. Wouldn't go against that
right now.
phil: also defer because the concepts need time to mature. Discussion
with fantasai indicated named lines got verbose because you're
naming all 4 edges.
phil: but with template syntax only need to assign one value.
phil: When using named lines, theory is you want something that says
this is my header start line, header end line. Need pairs for
both row and column dimensions. Now if you want to change
definition of grid, relocate those four names. With that model
you're going to have 4 names x number of grid items that you
want to make maintainable. That's lots to type - haven't created
ease of maintenance tool.
phil: not convinced that named lines actually solve the problem we set
out to solve. Not positive that templates are better.
phil: but shorter to type, and talking about regions instead of items -
can't type 2 letters in same spot.
phil: argument against template system is it doesn't give full power
of grid.
phil: both of these areas could use some bake time.
* sylvaing notes we have now spent 25mn on the same issue
plinss: let's move on
<Bert> names require you to think of names, where there actually is no
semantics, and it is not extensible for auto-placement
(a-priori unknown # of rows)
bert: need numbers anyway
bert: so that's enough to have in the core. Can add other notations later.
fantasai: next issue: discussion on mailing list about adding ability
to do gutters on grid lines so you don't need to create an
extra set.
fantasai: we said we could reuse the column-gap property
fantasai: so also add row-gap for other dimension
bert: not necessary, very limited - can only have one type of gap for
all columns. If you have something that spans multiple columns
where does the gap end?
fantasai: would span over the gap.
tabatkins: one of the reasons you need this kind of gap - if you want
to do flex box in a grid you can kind of do it <draws on board>
tabatkins: but you can't specify gutters. If you do them as empty rows
and columns the content will try to expand into them
tabatkins: really want a declarative mechanism
stevez: why isn't that a property of a track?
phil: tracks don't have properties because there's no track element to
style
tabatkins: could put into grid rows, but is unclear which track the
gutter would belong to
phil: they're the spaces between the tracks
tabatkins: probably almost always want uniform gutters
stevez: not objecting to simple mechanism, but bert's point was that it
doesn't provide arbitrary gutters. So a separate mechanism for
specifying a col or row that is intentionally blank seems to be
a useful feature.
stevez: was in original proposal
tabatkins: +1
fantasai: in the cases where you want non-uniform gutters, usually you
have small number of elements that you're styling individually
anyway. Easier to use margins for that.
phil: so uniform gutters mean we could just adopt column-gap and define
row-gap. If we want a non-uniform mechanism we'd need to provide
a list of gutters or something
markus: sounds like a great feature for next level
stevez: actually I was saying you could declare a column or row as being
a gap
phil: like a gap() function or something
bert: can leave that to templates. That's what they do
markus: sounds like agreement for a basic mechanism in spec
fantasai: next, some naming things. Grid spec has grid-flow, want to
align with syntax of flex-flow
fantasai: row means add more rows as you add content, column means add
columns, layer means create stack in the current cell
fantasai: previously row and column were flipped. Very confusing.
None becomes layer to be more clear.
markus: feedback from tooling people - really liked layer approach.
But others might want to do things other ways.
bert: alternative I had was to use grid-row property for that - have a
keyword that says this goes into next row, and one on column that
says this goes into the same column
fantasai: doesn't handle a lot of auto-placement situations because you
can't wrap onto the next line. If you have 100 items and just
want them to flow into a grid, can't do that without nth-child.
* sylvaing are we resolving anything?
fantasai: if you throw in different spans, definitely can't do that.
bert: can do that with normal selectors
tabatkins: yeah need to explicitly do it. More complex than it should
be for the use case.
bert: normal case is that you don't fill lines but that certain elements
need to be in particular places.
tabatkins: still really easy to do in this syntax
fantasai: both use cases useful, each set of syntaxes can do things the
other one can't. So we should have both approaches.
bert: e.g. I want to have a table, transposed. That's easy to do by
saying every td:first-child goes into the next column
howcome: are you saying this is possible with grid flow?
bert: yes
phil: grid flow would be property of grid. Not targeting individual items.
bert: but if you want every <tr> to start a new column, then (??)
markus: so we all agree basic functionality should be there but are now
talking about finer points. Move to email? Both approaches have
value, different ways of achieving same thing
<Bert> tr {grid-flow: column} td {grid-flow: row} or
td:first-child {grid-column: next; grid-row: 1}
discussion about repeat patterns and whether row means row
* sylvaing feels sorry he suggested resolving something
RESOLVED: rename the values of grid-flow so that row adds rows, column
adds columns, and layer just stacks grid items on top of each
other.
<Bert> (So if 'grid-flow' doesn't influence the autoplacement, how do
you say where the next child goes?)
phil: let's go back and see if there are resolutions on the other ones
too. Gutters:
plinss: we only had a dissuasion, no conclusion.
bert: we don't need them. We can use margins.
tabatkins: margins don't collapse. So you get double-wide gaps in the middle.
tabatkins: you want 0 on the edges and 10 on other lines. Can't do it without using nth-child
<Bert> div::slot(a) {margin-left: 10px}
phil: also can't center the margin on the line
phil: are there any objections to adding these?
bert: certainly not in the core, they might hurt us later
stevez: same as multicol?
bert: I think we're doing the wrong thing but won't give an objection
<BradK> I'm in favor of gutter gaps
bert: I've never needed it. Why add it?
phil: I didn't hear your solution to putting the gutter down the center
of the line rather than on one side.
RESOLVED: add row-gap and column-gap to the specification such that they
provide uniform gutters
phil: lines versus tracks as numbering. I don't think we'll get a
resolution on that but we have an action.
ACTION plinss to read new version of spec and provide feedback to phil
<trackbot> Created ACTION-461
phil: alternative addressing schemes. grid template syntax with lettering
of cells and named lines - proposing that they are deferred
<Bert> I think Elika's split means:
Core = 'grid-rows', 'grid-columns',
'grid-position-{x,y}' (incl. same/next/auto-placement),
'vertical-align' (or equiv.),
and the constraint system to calculate sizes, pagination.
Rest = 'grid-template', 'grid' shorthand, ::slot(), 'flow',
(and then in level 4: 'chains', page-based grid templates)
phil: do we have a resolution or action?
stevez: not in favour
stevez: worried we won't ever specify these modes
dbaron: I think that if you think the feature is important you should
keep it in
dbaron: not familiar enough with specification to have strong opinion,
but reasoning is dangerous because you can take a long time to
get back to things
plinss: I share steve's concern that by not having it in level 1 you
won't teach people to use it the right way
fantasai: would prefer to keep template rather than named lines, agree
that named lines syntax is really awkward.
plinss: I propose we revisit this when I have had a chance to provide
feedback
<BradK> I hope we can at least keep templates.
stevez: I'm concerned that moving templates out of this spec and into
bert's changes behavior. It's a non-trivial change.
phil: I think there needs to be clear scope separating these two specs.
Right now there's significant overlap, with some conflicts.
<BradK> Templates and grid go together very well. Like chocolate and
peanut butter.
phil: beyond that, there's additional functionality in the templates
spec that we don't want to see come into the grid spec.
fantasai: declaring grid, positioning, templating and layout algorithm
are in both specs and incompatible.
fantasai: need to move them into one place
bert: more compatible than they used to be.
sylvaing: but still in 2 places
stevez: I'm concerned that if templates are to provide a named interface
to grids, having them in a different spec is a bad idea.
fantasai: well that's fine, they still need to be in just one spec
phil: have had 2 specifications because of disagreement on some
functionality.
phil: needs to be a resolution about which model to support, and which
specification to put it in.
plinss: don't have enough time to solve this right now.
ACTION Markus, Phil and Bert to get together and work out how to resolve
the templating specifications to remove overlap
<trackbot> Created ACTION-462
<PhilCupp> thanks for great grid discussion... dropping off call
Present:
-Phil Cupp
-Daniel Holbert
-Markus Mielke
CSS3 Fonts
----------
Scribe: dbaron
<jdaggett> http://lists.w3.org/Archives/Public/www-style/2012May/0369.html
jdaggett: I just dropped in url for post I sent a few days ago
jdaggett: CSS3 Fonts defines support for font features. Designed to
enable features if they exist in the font, but we don't provide
a fallback.
jdaggett: But there are a couple of exceptions where we do provide fallback:
jdaggett: For small-caps, if a font doesn't have small-caps glyphs,
user-agent will synthesize
jdaggett: Other case where we do fallback is superscript and subscript,
which is semantic, so requires fallback
jdaggett: [Shows demo]
jdaggett: I have a bunch of fonts with subscript and superscript variant
glyphs
jdaggett: this shows what you see with browsers today and with variants
jdaggett: first is the subscript variant designed by the type designer --
the weight is designed to match the weight of what it's in
jdaggett: the third shows what happens when you shrink it down -- it
looks lighter
jdaggett: these special subscript/superscript glyphs are designed in the
same design space as the font -- there's no resizing/offsetting
for the subscript/superscript when using the glyphs designed
for it
jdaggett: the way we do subscript/superscript today we modify the baseline
(vertical-align: sub/super) and reduce the font size
jdaggett: To use the sub/super glyphs, you have to not do that
jdaggett: The font also has metrics that say the suggestions of the font
designer for where the subscript should go (position & size)
jdaggett: the middle (red) item is a super/sub sized and positioned based
on these metrics
jdaggett: they're not matched to the variant glyphs (e.g., less offset
in Minion)
jdaggett: or, e.g., in Whitney, the metrics are bigger and less offset
to compensate for the weight
jdaggett: problem with this: in a situation where some characters are
supported and others are not, it's difficult to synthesize a
matching combination
(clarifying question from vhardy about diff betw 2nd and 3rd)
jdaggett: so, if we just use variant glyphs, we'll have problems:
jdaggett shows Minion Pro having variants for "(", "2", and ")", but
not for "[" and "]"
jdaggett: in the first link, one of my first points is that when we do
fallback, we need to do it across the entire text span
jdaggett: so we synthesize even when part of the text span supports
part of the variant glyphs
jdaggett: So with Minion pro you'd synthesize all of "[2]" but would
use variant glyphs for all of "(2)"
jdaggett: The metrics aren't there in the font to let us synthesize on
a per-character basis
SteveZ: So this is unusual since we're doing glyph substitution on a
per-span basis rather than per-char basis
jdaggett: The other problem we have here is that we have this existing
mechanism for superscripts and subscripts that does it in a
structural way
jdaggett: coming up with a backwards-compatibile way of doing this is hard
jdaggett: since if you use the designed glyphs, you need vertical-align:
baseline and inherited font size, i.e., need to turn off
existing mechanism
jdaggett: see testcase in bottom of post
jdaggett: you can see that for this case we're turning on font-variant
position superscript and turning off vertical-align and
font size reduction from default style sheet
<BradK> How do you define text span? All the text in an element?
Including text that is inserted later?
SteveZ: One side effect is that I no longer sure how to compute the
vertical extent of the subscripts and how they affect line
height according to css
jdaggett: in my mind, this should have no impact on the line box
jdaggett: when the designer put the metrics in, they're designed so
they're just like any other character
SteveZ: so there's no actual baseline shift
fantasai: there's a visual shift, but no actual shift
jdaggett: So whether it has subscripts or not, this will produce a page
that doesn't have varying line heights
jdaggett: there was a proposal (see post) from fantasai and dbaron to
come up with something that would shoehorn magic behind the
scenes so when this matched vertical-align, you'd undo the
vertical-align and font size changes
jdaggett: what this won't do is cover the case where you have nested
subscripts or superscripts
jdaggett: (replying to Florian) fonts never have glyphs for nested
sub/super
jdaggett: And this won't line up with images (since you're not getting
the baseline shift)
jdaggett: So this can only do a subscript of the super/subscript stuff
you can do today.
Florian: So if you have an image and glyphs, you can't use the special
glyphs
jdaggett: So what I'm arguing for is that we have less magic, and authors
have to be aware that this is only typographic sub/super and
not structural
fantasai: So if authors try to use this for sub/super, the
sub/superscripting will fail for nesting or non-text
jdaggett: Details of original post by fantasai/dbaron rely on metrics
which doesn't work since these metrics aren't right
jdaggett: I think you could still come up with magic that ... .
jdaggett: There's existing content that's out there, so it's safer to
say that: here's how you do this, cover the 90% use case
(just text, short runs).
jdaggett: Do we need to talk more about alternate proposal, wanting magic?
fantasai: How do you determine bounds of text run that needs to be
considered together?
jdaggett: No wording for that yet.
jdaggett: Wanted general agreement for it first before getting to actual
wording
jdaggett: Thinking roughly: across spans of contiguous text (but can
span sub-elements)
SteveZ: If I've got a span, and turned on typographic sub/super, and
do a baseline shift inside that, what happens?
jdaggett: You get a baseline shift -- probably not going to look right.
peterl: I'm not seeing in the email how you turn on this type of superscript
jdaggett: just turn on font-variant-position
jdaggett: There's an example in the spec that includes the turning off
of v-a and font-size
TabAtkins: and for fallback, @supports queries
Bert: That example tests whether the user-agent is able to do this, but
doesn't check whether the font has a suitable glyph
jdaggett: Supporting the property means the UA will do fallback if the
font doesn't support it
SteveZ: That's the new piece added this time around
fantasai: I'm not totally convinced we shouldn't be doing something
smarter where people are putting elements inside it
fantasai: I like the idea of doing the idea of fallback at a span level
Liam: Isn't the answer that if you're already deciding not to use the
native glyphs, then if you find an element inside, fall back to
synthetic mechanism for the whole thing?
fantasai: The way it's defined right now, super inside super wouldn't nest
jdaggett: It's bad if you think it has to support that -- but I don't
think we need to support that.
jdaggett: There's already a default mechanism that allows that.
peterl: If the designer specifies font-variant-position: sub, they'll
get scaled down glyphs as fallback, right?
jdaggett: yes
Bert: ...
jdaggett: ...
Bert: ok, but I can see examples here... in general, do fonts scale down well?
fantasai: It's better if you don't scale and use the appropriate glyphs
jdaggett: the point here is to use the glyphs in the font
<Bert> (I was thinking of the TeX fonts, which actually use slightly
different glyphs for 8pt and for 10pt, so that you can use
them together.)
dbaron: How does this handle underlining?
dbaron: That's sort of a common case
dbaron: e.g. used in Wikipedia
szilles: underline isn't affected generally
dbaron: no, if you draw the underline just for the superscript
dbaron: how do you get that position correctly
jdaggett: so the answer here is that the underline will be drawn at the
main baseline
fantasai: you might wind up doing fallbacks in the case of text-decoration
plinss: in Wikipedia, the decoration appears only on :hover -- that's
not going to work
peterl: Well, on wikipedia the underline only shows up on :hover, which
would mean doing fallback when there's decoration wouldn't be
so great
dbaron: you'd switch into fallback on :hover
ACTION jdaggett: figure out text-decoration interaction with
font-variant-position
<trackbot> Created ACTION-463
ACTION jdaggett: define what scopes the run of things falling back
<trackbot> Created ACTION-464
proposed resolution: accept two points in
http://lists.w3.org/Archives/Public/www-style/2012May/0369.html
pending actual wording from jdaggett
fantasai: I'm less comfortable with second one since if you're styling
content and didn't account for some of the stuff that's in
there you'll get weird behavior
jdaggett: I think we can resolve on this and then we can have caveats
fantasai: Ideally, I'd like this to work in the general case
jdaggett: I think that's a good ideal, but that ends up not serving
the 90% case very well
fantasai: I want to solve both and I think it's possible
jdaggett: I disagree... but if you have another proposal we can talk
about that
SteveZ: informational question: if in the middle examples, I wanted
to make "2" black, so I put a span <sup>(<span>2</span>)</sup>...
jdaggett: my action item to figure that out...
jdaggett: My intention is that it's a contiguous text run; need not be
one single element, so it would work
jdaggett: if you say <p>f<span>i</span> in Firefox today, you'll see a
ligature that's half black and half red
peterl: fantasai, ok with resolving now, and you can maybe come back
with improved proposal?
fantasai: ok
<jdaggett> http://lists.w3.org/Archives/Public/www-style/2012May/0375.html
fantasai: I agree 100% with the first point
RESOLVED: accept two points in
http://lists.w3.org/Archives/Public/www-style/2012May/0369.html
jdaggett to provide actual wording
jdaggett: relatively minor point about small caps
jdaggett: with a font that has either small-caps variant or doesn't,
we have the fallback be determined by whether the font itself
supports small-cap glyphs
jdaggett: i.e., that we don't do per-glyph checking
jdaggett: That's different from the super/sub case.
jdaggett: Good reason for this: fonts typically support all or nothing,
unlike for sub/super where they typically support only a few
chars
peterl: Typically, or universally?
jdaggett: Close to universal
jdaggett: A font like Arial is not actually designed by one person,
designed by several people.
jdaggett: Can get cases where Latin, Cyrillic work, Greek doesn't
jdaggett: so I want cases that this can be done on a per-script basis
jdaggett: which would allow user-agents to do this check on a per-script
basis
jdaggett: per-glyph checking is a much higher implementation cost
jdaggett: there's a difference in the way the model works, but warranted
by the nature of the font
jdaggett: there's always the potential that what a browser would synth
is not precisely what a font would do
jdaggett: because of casing rules, e.g., for Greek
jdaggett: so there's potential font won't match browser casing rules
jdaggett: So, e.g., if you were to take a font that supported small-caps
and strip out the information that enables it and have the
browser synthesize it, those two results may not necessarily
match the same set of characters, because the browsers upper/
lowercase may not be what the font designer used when he set up
the small-caps feature.
fantasai: Does Greek keep diacritics in small-caps (rather than all-caps)?
jdaggett: I'm saying there's room for differences
jdaggett: I wanted to directly tie uppercase and lowercase function to
text-transform
jdaggett: I want the handling of synthetic small-caps to match the casing
used in the text-transform feature, which means the check for
"do I need to small-cap this glyph" uses the same case
transformations that are used for text-transform
fantasai: There are 2 casing things you need to do:
(1) check "is this glyph lowercase?" and if so synthesize a
small-cap and
(2) convert from lowercase to uppercase and shrink the glyph
fantasai: (2) is where you need the case transform table
jdaggett: And I'm saying that should match text-transform
fantasai: the wording here is really vague:
fantasai: capital letters are not affected by small-caps
jdaggett: but are by all-caps
fantasai: so you want to say only bicameral scripts are affected
jdaggett: I want to say it's exactly like text-transform
jdaggett: i think these 2 features should be consistent
* fantasai just thinks the wording proposed is confusing
SteveZ: implied text-transform...?
jdaggett: I'm just saying the case transformations used for small-caps
are the same that are used for text-transform
SteveZ: ...
jdaggett: The reason for that is that if text-transform puts in special
rules for special casing, we don't want to have to go back
and modify two specs
fantasai: I Think you have a good point but the wording is confusing
jdaggett: I'll rework the wording
ACTION fantasai: propose less confusing wording
<trackbot> Created ACTION-465
jdaggett: only other thing about css3-fonts is that I published today
revised wording of font-family syntax from the last telecon
Håkon: formal grammar?
jdaggett: Yes. Deal with inclusion of 'inherit' within font family
name, e.g., 'font-family: foo inherit' is invalid
jdaggett: saying you need quotes in that case
Bert: you said you put in some text
jdaggett: on the mailing list
jdaggett: I'm piggybacking on changes I proposed for css3-values,
issues with case sensitivity.
Bert: It's a change from CSS 2.1
jdaggett: Fixing ambiguity, I don't think it's a change.
Tab: We already resolved on this last week or the week before
Bert: The resolution I recorded was ...
Tab: That wasn't the resolution we were trying to get
Tab: If you want to reopen, please do it on the mailing list
Bert: we should not change 2.1
Bert: 2.1 is very clear except for the case where there is a font name
called inherit, unquoted
tab: anything else?
ACTION fantasai: review css3-fonts wording on font-family syntax
<trackbot> Created ACTION-466
jdaggett: I'm done. Just from a spec level I'm trying to go through
the spec, publish another WD in the next couple weeks.
jdaggett: Last sticky issue is font matching for clusters (base characters
with combining diacritics, variation selectors). Once that's
ironed out I think will want to consider moving to last call.
jdaggett: fantasai has some comments about @feature-values to post to
the mailing list
jdaggett: past that I'll start asking people to take a look at the spec,
look for things ambiguous, unclear, could be better explained
Spec Editing Tools
------------------
vhardy: last time I showed a tool to help editors with issue tracking
vhardy: if you want to use bugzilla to track your issues and make sure
they're in your spec
vhardy: a tool for editors, not meant to be published
vhardy: checks for issue markers and checks bugzilla
vhardy: Will tell you if you have issues that are resolved that should
be removed, or new ones that should be mentioned in the spec
vhardy: I put this in the shared repository under root of spec directory
Florian: only bugzilla, not tracker?
vhardy: right
Bert: way to put this in postprocessor rather than only insert when
you're online?
vhardy: you need to insert issues at a particular point in your spec
Bert: but I put the issue number in the spec
Bert: because it's not done by the postprocessor I have to make a link
myself
Bert: I'd like to just put ISSUE -dash- 217 and have the postprocessor
just make it a link
vhardy: I don't have access to the postprocessor
Bert: wondering if this code is readable enough...
vhardy: I didn't write it... but his code is very legible
plinss: on this topic, we were talking about test annotation script
plinss: Tim doesn't allow us to have it on /TR/
plinss: But he will allow us to add to /TR/ specs a link to an annotated
version
plinss: so thinking of putting /TR/ specs mirrored on csswg.org
plinss: because it makes specs in /TR/ mutable based on something off
of w3.org servers
plinss: can do annotations and anything else we want there
Meeting closed.
Received on Tuesday, 15 May 2012 20:51:36 UTC