- From: Dael Jackson <daelcss@gmail.com>
- Date: Mon, 13 Feb 2017 20:58:20 -0500
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
Text Track
++++++++++
Text Decoration
---------------
- fantasai introduced her draft of Text Decoration Level 4 for
discussion: http://drafts.csswg.org/css-text-decor-4/
- She will add examples for offset based on different anchor
points.
- There was some question as to if 'width' was the right word
for text-decoration-width. It was given that name for
consistency with properties like with border-width and
stroke-width, but may still need bikeshedding.
- There was support for use-font to allow specifying user
value in the font.
- RESOLVED: FPWD of text-decoration level 4
(http://drafts.csswg.org/css-text-decor-4/)
- The relative position example for text-underline-position was
reviewed and found helpful in identifying correct behavior.
Step-Sizing/Rhythm
------------------
- There was concern about having this as a separate spec from line
grid as they'll be used together frequently. They will stay
separate for now and an issue about it will be raised on the
FPWD.
- The name also concerned some people, but there wasn't a better
idea right now.
- RESOLVED: First published working draft for step sizing
(https://drafts.csswg.org/css-step-sizing-1/).
- RESOLVED: koji, fantasai, and dauwhe as co-editors.
- RESOLVED: Rename to css-rhythm
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/seattle-2017
Note: The group split the morning of the 12 January on two
tracks: FX and Text.
Scribe: zcorpan
Text Track
++++++++++
Text Decoration
===============
<fantasai> http://drafts.csswg.org/css-text-decor-4/
fantasai: I drafted up a text decoration module.
fantasai: Plan so far is to add ... text-shadow I haven't added.
text-decoration-width
---------------------
fantasai: Added text-decoration-width
fantasai: ideally you get that info from the font for auto
fantasai: but here can specify a length
fantasai: doesn't cascade independently from color etc.
text-underline-offset
---------------------
fantasai: text-underline-offset which needs overline offset also...
fantasai: if you specify a length, disables automatic adjustments,
just starts at origin point
fantasai: which origin depends on the value of
text-underline-position.
fantasai: (reads from spec)
fantasai: Positive moves up, consistent with how vertical-align
works.
Florian: I expected the opposite.
fantasai: Wanted to align with vertical-align.
fantasai: Technically it's inward rather than up, so underline
flips sides it goes in the right direction as
appropriate.
fantasai: If you're starting with under edge it will go up.
fantasai: Consistency with vertical-align is important.
Consistency with font coordinate is also important.
eae: This makes sense to me.
fantasai: Currently UAs are allowed to make automatic adjustments
for font changes
fantasai: but not the case of vertical-align changes
fantasai: Similar effect with automatic baseline.
fantasai: What happens is the underline is slicing through the
text, so can move it.
fremy: Green one is what edge is doing.
koji: ???
myles: 2 spans with different box sizes?
fantasai: Inside there's a big text element. nested spans.
fantasai: small text span has small underline ...
koji: webkit and blink does low text position.
fantasai: Question is, do we want this property to also disable
these automatic adjustments?
astearns: We can ask authors
astearns: leave as is for now.
astearns: Anyone have an opinion on this?
fremy: Specifying the properties is fine but giving control to the
author will produce different results anyway.
fremy: Author will try in one browser and then give different in
another browser.
fremy: Auto value should just do nothing.
fremy: Specify some other completely different behavior for other
values, that can be consistent across browsers.
astearns: Agree for the case where it is author-controlled.
fantasai: We should do that also.
fremy: Gecko is using only elements where you specify underline
fremy: edge uses the entire text range.
fremy: Violation of the spec but produces better results than
gecko.
jensimmons: link?
<fantasai> https://drafts.csswg.org/css-text-decor-3/#text-underline-position-property
koji: Question about offset:
koji: Table sets initial position alphabetic baseline
koji: What offset is not specified when it's under....
koji: for auto we draw slightly below baseline.
fantasai: 0 is exactly at alphabetic baseline.
fantasai: If we start from the UA chosen position the author won't
know where that is
fantasai: 0 at baseline is better
Florian: Is this going to make authors want a descender unit?
fantasai: Have control over where the origin is -- use
'text-underline-position: under' if you want the bottom
edge
ACTION fantasai: add example to offset from different anchor points
<trackbot> Created ACTION-819
myles: Is there a reason why you chose to center the thickness[?]
myles: Should grow outward.
fantasai: ok
SteveZ: Can change width without changing position.
fantasai: Sounds good.
myles: Reason we use the word width?
fantasai: Consistency with border-width.
myles: Width is usually a metric vertically.
fantasai: Not true for border-width.
fantasai: Better to be consistent with border-width, stroke-width,
etc.
astearns: Should list it as a mistake to call things -width,
should have been -thickness?
Florian: Too long.
<jensimmons> *** I want to concur with myles that
text-decoration-width is confusing.
<jensimmons> *** having a hard time getting a chance to speak
koji: Proposal that we could have a value to specify user value in
the font.
fantasai: That's auto.
myles: Don't think so.
myles: I tried to make auto take into consideration what the font
says.
myles: Terrible results.
myles: Having taken the font's metric into consideration ...
should be separate thing
myles: use primary ...
Florian: Because fonts are broken?
myles: Right.
myles: So should be separate value.
fantasai: We have a keyword somewhere for this.
fantasai: Can't remember what we used it for.
SteveZ: ???
fantasai: Looking at text-decor-4....
fantasai: use-font keyword.
fantasai: Sounds good.
SteveZ: Why vertical text is alphabetic baseline is the choice
fantasai: Will want that in some cases.
fantasai: Auto keyword, should be able to specify offsets from
there...
SteveZ: agree ...
fantasai: For vertical text, Japanese/Chinese, will get left or
right line rather than alphabetic line.
SteveZ: Get ransom note underlines.
fantasai: Position of underline in vertical text depends on
language; English text in a Japanese book is on the left
even when Japanese text is on the right.
fantasai: Position of the underline is controlled by the
underlining element, not descendants, so won't get
ransom note effect.
text-decoration-width naming
----------------------------
jensimmons: Concur with myles concern about having width for
underline will be confusing.
jensimmons: Can bikeshed it later.
jensimmons: underline ... width seems like how wide it is.
jensimmons: text-decoration is already hard to remember.
myles: You still have to use the phrase "text-decoration" to turn
it on.
jensimmons: Yes. Not suggesting to change that.
fantasai: We can in the future decide ...
jensimmons: I'm advocating "thickness" or similar word
fantasai: 1) too long
fantasai: 2) because we're using width for stroke-width, is
consistent, which is especially important for
non-English speakers
jensimmons: I understand. But still confusing I think.
fremy: More people don't speak English.
fremy: Size?
myles: Might be worth it to be inconsistent.
astearns: It might but will not figure this out today.
text-emphasis-skip
------------------
fantasai: text-emphasis-skip
fantasai: Allows you to say which characters are skipped
fantasai: Typically you skip spaces and punctuation.
fantasai: can skip other things as well
fantasai: This is so you don't have to put spans to get correct
effect.
Florian: Do we need the same kind of split into longhands as
text-decoration-skip.
fantasai: Don't think so, related set of things.
fantasai: That's it for what's in the draft.
Bert: Is 'text-emphasis-skip' part of the 'text-emphasis'
shorthand?
fantasai: It's not.
fantasai: It's usually a document-wide setting.
fantasai: May change later, e.g. for a particular headline.
fremy: If we have text emphasis and don't specify skip, value will
be inherit.
fantasai: Don't think we do that anywhere else
fantasai: shorthand resets everything.
astearns: things we decided to add ???
Miscellaneous
-------------
Florian: We should get an ED.
Florian: In the header you're linking to tracker, want to change
that?
fremy: Interested in having clear illustration for what expected
result should be for auto.
fremy: Should have pictures.
fantasai: It's in Level 3
fantasai: We'll add examples.
astearns: Also example for positive vs negative offsets.
fremy: ???
Florian: Open issue for that.
myles: Think it's doable for an impl to clamp values to reasonable
extremes.
fantasai: Good point. Should put that in.
fantasai: Ink overflow?
myles: Don't want super big underlines.
fantasai: 1) should allow UA to clamp offset values
fantasai: 2) specify that it's ink overflow
astearns: Some % of an em?
myles: Whatever is sane.
eae: We clamp font size.
?: Why clamp this?
fantasai: Features on the web are abusable.
fantasai: Shifting an offset, why can't I move it to anywhere on
the page...
astearns: Should we close off the L4 discussion?
astearns: Resolution for FPWD?
fremy: webkit-text-field can specify an image
fantasai: Issue for paint spec.
fremy: If it's considered part of the text.
fremy: ???
myles: I imagine it would be, this is how I do overlines....
myles: Should clarify to not use text-underline-offset for
overlines
fantasai: yeah ok
fantasai: By April level 3 should be stable enough
myles: Provides valuable use cases
Florian: Together with cap-height ...
Florian: The thickness/width thing
Florian: when it's wavy, thickness of the stroke?
fantasai: Don't think it's specified.
fantasai: If you say straight/wavy, the amplitude of the wave is
greater than the thickness of the straight line, which
is more like the thickness of the wave stroke.
SteveZ: ???
astearns: Anyone object to FPWD of level 4
Florian: Pending edits sounds good.
RESOLVED: FPWD of text-decoration level 4.
?: Why is it a diff spec? Diff specs are bad.
fantasai: Have to balance badness of diff spec with maintenance
issue.
fantasai: Atm, because Level 3 parts are going through changes,
doing a diff spec to make it more maintainable and
less risk to introduce errors
fantasai: It's reasonable to fold in when the lower level draft
has entered 2nd CR phase.
fantasai: Flexbox went through this double phase, 2nd phase is
much more stable.
SteveZ: Content of this spec is what's in previous...
fantasai: We should publish early and often.
fantasai: Other option is to hold off publishing.
tantek: Should have more info in intro about why it's so empty.
SteveZ: Abstract could say that.
tantek: Or status.
fantasai: Section 1 is basically that...
Bert: ok
<tantek> I was thinking in generic language that we could perhaps
include in other delta specs too
<astearns> we should have a standard "include level n-1 content
here" issue (from bikeshed?) and a standard intro issue
describing diff specs
text-underline-position
-----------------------
astearns: level 3?
fantasai: text-underline-position
fantasai: Auto value which is like alphabetic most of the time
fantasai: used to have alphabetic, but request to drop that so we
did
fantasai: left/right which do under
fantasai: restrictions/allowances of where to draw the underline.
fantasai: (reads from spec)
Florian: Subscript is not to avoid ???
SteveZ: First 1st is correct? or both?
fantasai: Both correct.
fantasai: Can use offset value from OpenType.
fantasai: Baseline alignment causes boxes to be positioned
slightly offset
fantasai: edges of the boxes won't necessarily all align
fantasai: UAs is expected to accommodate those things
fantasai: don't adjust for that shift
fantasai: Just adjust for baseline alignment, not baseline
shifting.
SteveZ: No difference between font size change.
fantasai: Right.
fantasai: If alphabetic baseline in two different fonts are
different... UA will account for that.
SteveZ: Subscript can use skipping.
fantasai: Yes.
fremy: Transform?
fantasai: We ignore transform
SteveZ: Transform is applied after.
fantasai: Yes.
fantasai: Relative position is more interesting.
fantasai: Different impl do different things, should try to make
the spec match what UAs do or want to do.
Florian: Do you know if the range of variations is inside the
allowed spec things?
fantasai: Outside, do the thing that is not allowed.
fantasai: Red thing is wrong.
myles: I think this is a good direction.
myles: We don't follow it but that is bad. Positive feedback!
astearns: A bug for this?
Step-Sizing
===========
Scribe: eae
<koji> https://drafts.csswg.org/css-step-sizing-1/
astearns: Not sure what the right order of discussion is.
koji: I have updated the spec since last time I asked for a
review, primarily I got feedback on three items.
koji: First one, inline-width stepping, we think it's nice to do
but consensus was that it is lower priority than height.
Propose to defer. Was removed from spec.
koji: Second thing; baseline feature from previous draft. Similar
feedback, concerns about baseline, lower priority than other
features. Was also removed.
koji: The only feature remaining is line-height stepping.
koji: Last feedback, a few people wanted to have block height in
addition to line height. Only line-height stepping is too
fragile. Having block-height as well makes it more stable.
koji: Spec has been under discussion for over a year, propose to
publish draft as is and then work together with fantasai to
update and come up with new working draft.
fantasai: We should have all features for the first working draft.
fantasai: Can sketch up for first publish based on email.
<fantasai> https://lists.w3.org/Archives/Public/www-style/2016May/0089.html
fantasai: The part you have written is more concrete, if we want
to add more details later to this part we can do that.
astearns: We should at least have the outline in the draft.
dauwhe: Copy email into github issue 490.
Florian: I used to have concerns with this spec, but I have no
strong objections for the remaining parts. What has been
sketched out so far has missing pieces but no worrying
aspects.
Florian: One of the reasons for the spec taking so long to approve
is due to objectionable parts of the spec rather than
missing pieces.
Florian: Will not block current suggestion.
fantasai: First public draft doesn't have to have all of the
details, goal is to get the feature there so people can
see what it looks like.
astearns: If line-step sizing goes ahead and block step sizing
does not we can then move that to the next level.
Concerned about adding block step sizing later on.
SteveZ: Not prohibited by process, there is a second step.
Florian: Once we have sketched out the block part, if there are
still concerns we should take it out.
SteveZ: You can always mark it at risk.
SteveZ: There are important use cases only addressed by block step
sizing.
fantasai: With block step sizing I think we can get to 80% of the
uses cases, without it much less so.
astearns: Getting the outline and publishing the draft sounds like
the way to do it.
myles: Is the idea that browsers in the future will support this
*and* line grid?
astearns: Yes.
Florian: Once you have this and line grid, it is not clear that
there are many cases where you want to use this alone but
I can see uses for this and line grid being used in
conjunction.
Florian: You set your line height which gives the rhythm for the
line grid, if you then have sup/sub or different font
sizes...sometimes it is enough to adjust the line grid,
sometimes not. You don't want double spacing. Combining
line grid and step size might be a way to adjust the
slack that sticks out.
myles: Sounds like that shouldn't require this, should be part of
line grid.
fantasai: There used to be a slack property in line grid, iirc.
astearns: One example I have considered, I'm using a line-grid for
setting baseline. There are also graphics using line
grid. Currently fuzzy, only does positioning of the
elements. Only adjust positioning, seems appropriate,
shouldn't also change sizing. Step size can be used to
control the sizing.
fantasai: I think line-grid proposal would support that and resize
the box.
astearns: Should be a separation of concerns, line grid should
only change position and then step sizing can control
size.
fantasai: That reminds me of some of the grid proposals. Original
Msft proposal separated grid start idex and grid span =
specifying position & size, end position implied.
But new grid proposal is based off start/end lines,
which imply spanning size. Imho line grid should be the
same.
fantasai: When you fall off your rhythm, you have to figure out
how to handle that case. Line grid and step sizing
handle that differently. You might value one behavior
over the other.
When there is a missized item in line grid, you preserve
rhythm absolutely but there is a gap. For step sizing,
no gap, just break in rhythm. One might want one or the
other. Not unreasonable to have both features.
fantasai: Having a gap in the content on continuous media looks
bad, little benefit. But if you have parallel columns,
having the gap to get cross-alignment might be
appropriate. Depends on use case.
astearns: Put another way, there are examples in the line-grid
spec that have examples that do not fit the rhythm as
the gaps would be too big. There are extra things in
line-grid to avoid that. We might be able to remove
line-grid complexity be using step-sizing.
fantasai: I think that's a different thing.
myles: There are differences and both have uses cases. Interop
between the two could be complicated and for many authors
that might be confusing. Especially as authors might only
know about one or the other. I think it would make a lot of
sense to have both described in the same document to
preempt that.
fantasai: Quite different model and the interplay isn't that big
between them. Would prefer to have them described
separately. Technical details are different, would
prefer in separate specs but am fine with a lot of
references between the two.
fantasai: In terms of technical work, having them in separate
models preferred and make it easier.
SteveZ: I can see a reason to put them together, there are
conflicts if both are turned on. On the other hand, from
an implementation point of view, step sizing likely to
happen much quicker than line-grid so they'll be separate
anyway. Having a note that explains how they work together
would be helpful. Might end up in one of the specs
eventually.
Florian: The risk of getting interaction wrong from having two
specs is minimized by having the same people working on
both. There is tension.
myles: If you fast forward 50 years, there will be two similar but
very different specs that are confusing. An author will
have difficulty figuring our which one to use.
Florian: If you put too much into a single spec it'll be
terrifying. The step-sizing part is comparably much
simpler. If you combine it that might scare authors away.
astearns: I share your (myles) concern for authors. We should
raise issues on the specs to clarify the potential
conflicts. Ideally before the 50 years pass.
myles: Of course this should be defined and speced.
SteveZ: No reason we cannot combine the two at some point in the
future. If we do that I propose we change the name of
step-sizing.
fantasai: We could also rename it later.
Florian: We might want to have a rhythm spec in the future.
fantasai: As we're talking about flying cars and the future, I'd
like to see not just snapping inlines but snapping to an
explicit layout grid, which people have been asking
about.
fantasai: Had that in mind as eventually direction when working on
the draft for line grid: support snapping to any line in
either line grid or explicit grid.
fantasai: Becomes a much more general purpose layout tool.
Florian: We'll eventually need to integrate with multi-col.
myles: Sounds like I'm being overruled, two documents solving
similar problems.
astearns: Wouldn't call it being overruled. I think this is a set
of concerns we need to keep in mind. You are welcome to
object to publishing a first working draft.
myles: Won't object.
SteveZ: Can we at least file an issue and put that into the first
public working draft?
Florian: Yes!
astearns: Any other questions/comments?
SteveZ: I really don't like the name step sizing.
Florian: Suggests how, not why.
astearns: Steve, are you going to object?
SteveZ: No, name is confusing but won't object.
dauwhe: Name is bad, also conflicts with snap.
fantasai: We did rename that to scroll-snap.
astearns: Lacking proposed alternate, will close subject.
RESOLVED: First published working draft for step sizing.
RESOLVED: koji, fantasai, and dauwhe as co-editors.
<br size=15m>
Scribe: fantasai
<fantasai> text issues that need help:
<fantasai> https://www.w3.org/mid/20150211003752.GA14268@pescadero.dbaron.org
SteveZ: Offline discussion to change name of css-step-sizing to
css-rhythm as CSS Rhythmic Sizing
SteveZ: Reason that designers are more likely to recognize that.
astearns: Actual reason is to see Koji dancing.
astearns: We're only changing the name of the draft.
astearns: Not making a property called rhythm, because nobody
knows how to spell it.
melanierichards: As a designer, I like the idea of using rhythm to
describe this, but line grid also seems like it
would fit under here.
SteveZ: That was intended, so that in future we could fit line
grid under here.
SteveZ: Basically, I think there was sympathy to what myles was
saying in the long term, just not in the short term.
esprehn: What are you going to call the inline-axis version?
dauwhe: Harmony.
Florian: It's not a certainty that we'll merge the specs in, but
we want to leave the door open.
RESOLVED: css-rhythm
Florian: Slightly related question: should lh and rlh be affected
by line-height-step?
fantasai, astearns: I think it should be.
astearns: We could just open an issue on the spec.
Florian: ok, I'll do that.
https://github.com/w3c/csswg-drafts/issues/937<div
id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br />
<table style="border-top: 1px solid #D3D4DE;">
<tr>
<td style="width: 55px; padding-top: 13px;"><a
href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon"
target="_blank"><img
src="https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif"
width="46" height="29" style="width: 46px; height: 29px;" /></a></td>
<td style="width: 470px; padding-top: 12px; color: #41424e;
font-size: 13px; font-family: Arial, Helvetica, sans-serif;
line-height: 18px;">Virus-free. <a
href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link"
target="_blank" style="color: #4453ea;">www.avast.com</a>
</td>
</tr>
</table><a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1"
height="1"></a></div>
Received on Tuesday, 14 February 2017 01:59:26 UTC