- From: Dael Jackson <daelcss@gmail.com>
- Date: Mon, 13 Feb 2017 20:19:25 -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
++++++++++
Hyphenation
-----------
- There was a general sense that the least harmful behavior is to
not hyphenate when there's no language declared.
- zcorpan and myles will work together to see if it's possible for
browsers to standardize the behavior based on how much is
already in the wild.
Text Decoration
---------------
- RESOLVED: defer issue 4
(https://drafts.csswg.org/css-text-decor-3/issues-cr-2013#issue-4)
- RESOLVED: defer issue 3 to next level
(https://drafts.csswg.org/css-text-decor-3/issues-cr-2013#issue-3)
- Issue 2 (https://drafts.csswg.org/css-text-decor-3/issues-cr-2013#issue-2)
needs more investigation before a resolution can be reached.
If it requires a change in initial value the change will have
to occur in this level, but a new feature could be deferred.
- RESOLVED: We reject issue 14.
(https://drafts.csswg.org/css-text-decor-3/issues-cr-2013#issue-14)
- RESOLVED: Reject issue 5 and follow up.
(https://drafts.csswg.org/css-text-decor-3/issues-cr-2013#issue-5)
- RESOLVED: undefined on issue #10.
(https://drafts.csswg.org/css-text-decor-3/issues-cr-2013#issue-10)
- RESOLVED: Go with Ken Lunde's suggestion for issue 13
(Issue:
https://drafts.csswg.org/css-text-decor-3/issues-cr-2013#issue-13
Suggestion:
https://lists.w3.org/Archives/Public/www-style/2016Dec/0094.html)
- RESOLVED: Accept fixes to handle fixes in default UA stylesheet.
(Issue 11:
https://drafts.csswg.org/css-text-decor-3/issues-cr-2013#issue-11
Issue 19:
https://drafts.csswg.org/css-text-decor-3/issues-cr-2013#issue-19)
- RESOLVED: text-emphasis-position: [ over | under ] && [ right |
left ]?
(Issue 17:
https://drafts.csswg.org/css-text-decor-3/issues-cr-2013#issue-17)
- fantasai will reach out to i18n to see if there's a use case for
the left value in text-emphasis-position.
- RESOLVED: Update spec to handle sideways-lr/sideways-rl as
rotated horizontal text
(Issue 20:
https://drafts.csswg.org/css-text-decor-3/issues-cr-2013#issue-20)
- RESOLVED: Omitted text-underline-position value defaults to auto.
(Issue 18:
https://drafts.csswg.org/css-text-decor-3/issues-cr-2013#issue-18)
- RESOLVED: Split text-decoration-skip into longhands.
(Issue 1:
https://drafts.csswg.org/css-text-decor-3/issues-cr-2013#issue-1
Issue 22:
https://drafts.csswg.org/css-text-decor-3/issues-cr-2013#issue-22)
- RESOLVED: In level 3, have text-decoration-skip-ink. Move all
other parts of skipping to level 4.
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/seattle-2017
Note: The group split the morning of the 11 January on two
tracks: FX and Text.
Scribe: dauwhe
Text Track
++++++++++
Hyphenation
===========
<astearns> hyphenation: https://github.com/w3c/csswg-drafts/issues/869
<astearns> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4761
<astearns> testcase^
zcorpan: It's non-interop whether hyphenation happens if there's
no language declared.
Florian: For hyphenation to work we need language tagging.
Florian: So if it works, this encourages authors to not pay
attention.
Florian: So if you don't declare the language, it shouldn't work.
zcorpan: There is resistance in the issue.
myles: This property has been around for years
myles: so they haven't been paying attention for years.
myles: Our browsers hyphenate, users would think there's a
regression if we changed this.
koji: We already rely on system language for font selection, etc.
koji: What's the criteria for when we do and don't want system
language-related behavior.
astearns: I think it's different than font selection.
astearns: We can fall back to system fonts.
astearns: I'm assuming there's lots of non-tagged content.
zcorpan: This only affects hyphens: auto pages
astearns: If we fall back to system...
astearns: So we could get different behavior for same
English-language page on different computers.
fantasai: If it's dependent on your personal system, then that's
bad for authors.
Florian: Legacy is a problem.
Florian: Having cjk look Japanese on Japanese computers and
Chinese on Chinese computers was a legacy issue.
Florian: The fact that hyphens: auto hyphenates is webkit only.
frenemy: Microsoft does it too.
fantasai: It won't make or break a web page.
fantasai: It's not interoperable now.
fantasai: It won't change how your layout works.
fantasai: It's a slight regression of typesetting quality, but
won't break pages
fantasai: unless they're already broken.
myles: Hyphenation will be off or weird if you have hyphens: auto
in lang x and reading in lang y
Bert: I often read pages in four languages, can't use my system
language.
astearns: Tagged in lang x, reading on system for lang y, wouldn't
you still use lang x dictionary?
myles: Only if it's not tagged.
myles: Content says hyphens auto
myles: written in lang x, not tagged, system in language y.
SteveZ: We're lacking relevant information like frequency of these
problems.
SteveZ: We're talking about the horses mouth without counting the
teeth.
SteveZ: If you're American, and you speak English, hyphenation
probably works.
SteveZ: If you have German system, read lots of English or Dutch
content, then you get lost.
SteveZ: It depends where you're looking.
SteveZ: Better to turn off bad hyphenation.
fantasai: Very common for people in Europe to read English
fantasai: They'll get incorrect behavior
Florian: Everywhere
fantasai: Most of Europe has the same writing system as English ->
conflicts.
fantasai: Our job is to promote interop.
fantasai: There's a split in UA behaviors
fantasai: it is not well established that you get hyphenation.
fantasai: If we take interop seriously
fantasai: then we need to not make things system-dependent.
fantasai: There is legacy stuff, but this is not that kind of
stuff.
fantasai: It doesn't break pages.
fantasai: Author can just tag the language.
<Florian> +1
<dbaron> +1
<zcorpan> https://www.chromestatus.com/metrics/css/popularity#hyphens
use counter for hyphens 1.8725% . in httparchive
hyphens:auto appears in 27,173 resources from 494,891
pages
zcorpan: There's use counter for hyphens property.
zcorpan: 27k resources out of half a million.
zcorpan: for lang attribute it's 2.6%.
zcorpan: 2.3% on root element.
<zcorpan> https://www.chromestatus.com/metrics/feature/popularity#LangAttribute
Florian: Are there stats for usage together?
zcorpan: no
<tantek> I'm curious what happens if we drop the <html lang="en">
from the count
<tantek> in my experience those are just copy/pasta from templates/
boilerplates
astearns: Given these numbers, would webkit be willing to change?
myles: This isn't enough information.
myles: There's four pieces; it's the intersection of the four
pieces.
Florian: We have a limited time to deal with this.
Florian: Because chrome didn't have hyphens, and has large market
share
Florian: so few people are depending on it.
fantasai: Very limited.
fantasai: Now is good time to change.
astearns: I agree we want interop
astearns: Could chrome and FF match webkit?
zcorpan: Chrome already matches webkit
zcorpan: Firefox is different.
myles: Having things be system language dependent is not contrary
to interop.
Florian: In font fallback there's two things-
Florian: helvetica vs times is ok
Florian: but Japanese can't look like Chinese.
Florian: We should always tag languages
Florian: but they don't
Florian: so we have to take from system for Chinese vs Japanese.
Florian: But with this case we don't have to take from system
Florian: most English readers are not native speakers.
koji: We do use sys lang for font selection.
Florian: Spell check is less crazy.
Florian: You're checking what the user is typing, and that's
likely in their sys language.
frenemy: On windows you have control
frenemy: system settings are user-modifiable.
astearns: We're drifting
astearns: I want interop.
zcorpan: I can file an issue on gecko
zcorpan: and I can try to get a figure on hyphenation: auto with
no declared lang.
astearns: zcorpan and myles can work on standard behavior
astearns: Is this a regression or whether this is something and
you can stick you what you have.
SteveZ: If I don't hyphenate that's safe from understandability
viewpoint.
SteveZ: If I do hyphenate in the wrong language, I can destroy the
understandability of the text.
SteveZ: Doing it when it's wrong is worse than not doing it.
SteveZ: The other point is
SteveZ: in this case, we shouldn't take the option of the easy way
out-
SteveZ: meaning FF doing what others do.
SteveZ: We should try to make the change so that lang is required.
SteveZ: It seems people want to do the right thing if possible.
<fantasai> +1 to what szilles said
dauwhe: hear hear
astearns: The approach of requiring lang for hyphenation is better
for readers.
astearns: We need to see if browsers can change.
koji: Same spelling of word can be different?
astearns: There's a bob dylan record-
astearns: the tambourine man-
astearns: on 1st printing, it was hyphenated as tambor-urine
astearns: which changes meaning.
Florian: It's wrong hyphenation but not caused by wrong language
astearns: That could be.
astearns: We're not going to make more progress today.
astearns: Need action for which way forward.
Florian: Big difference between font selection thing is that font
selection is local problem, mostly for non-international
languages.
Florian: English is everywhere.
Florian: hyphenation happens to international languages.
Florian: there are more and more things in text that require
language tagging.
Florian: we should push on authors.
koji: 60% of pages are lang tagged.
myles: I'm not worried about pages in the future.
myles I'm worried about pages that exist.
Florian: We're not encouraging people to do the right thing
<tantek> I'm really confused about the claims about language
tagging
<tantek> specifically the <html lang="en"> problem, and if we can
make things easier for authors we should! (instead of
trying to "force" them to do something like language tag
everything)
<Florian> tantek: which claim is confusing you? One I made?
<tantek> Florian yes, more the assumptions behind your claim.
<tantek> Florian we can discuss offline, usability vs making
authors do more work.
Text Decoration
===============
<fantasai> https://drafts.csswg.org/css-text-decor-3/issues-cr-2013
fantasai: disposition of comments^
<fantasai> https://lists.w3.org/Archives/Public/www-style/2016Dec/0121.html
fantasai: There are lots of issues that came up during CR.
fantasai: Starting at bottom of list 'cause they're easier.
Issue 4: Allow arbitrary decorations
------------------------------------
fantasai: First set are things that should be deferred.
fantasai: 1. allow arbitrary declarations, using @-rules
fantasai: This is issue 4.
<fantasai> https://drafts.csswg.org/css-text-decor-3/issues-cr-2013#issue-4
Florian: This was reinventing SVG
Florian: Yes.
myles: Can I anti-object?
RESOLVED: defer issue 4
Issue 3: Allow specifying position and thickness of underlines
--------------------------------------------------------------
<fantasai> https://drafts.csswg.org/css-text-decor-3/issues-cr-2013#issue-3
fantasai: Issue 3
fantasai: We should do this, but since it's a new feature it
should go in level 4
astearns: Agree to defer?
RESOLVED: defer issue 3 to next level
Issue 2: text-decoration-color vs SVG fills
-------------------------------------------
<fantasai> https://drafts.csswg.org/css-text-decor-3/issues-cr-2013#issue-2
Florian: Issue 2.
Florian: Interaction between text-decoration-color and svg fills.
Florian: We should work on this issue in the fills spec.
Florian: Might require changes to text-decor but we're not sure.
Florian: Isn't this a case of adding auto to solve the issue.
fantasai: Possibly.
astearns: Link in issue goes to a disambiguation page.
fantasai: I complied this offline. I will fix it.
Florian: Having text-decoration-color: auto is a possible solution.
Florian: Why don't resolve?
fantasai: Let's defer until paint spec is more complete, which
deals with fills and strokes.
astearns: Paint spec talks about script.
astearns: This says what's in svg changes things.
fantasai: I haven't thought thru how we'll make this all work.
fantasai: Let's figure out the paint spec, then figure out if we
need to change.
tantek: I agree with fantasai.
fantasai: SVG doesn't do anything for other things.
astearns: I'm ok to defer.
Florian: OK to keep issue open
Florian: but I don't want to close.
fantasai: We're not pushing for PR now
tantek: Could it be a new feature?
fantasai: It might need to be different initial value.
astearns: More about interaction.
tantek: We wouldn't add a new auto value?
fantasai: Current value is current color.
astearns: Leave issue open?
tantek: Unless you want to keep it open for a solution without
adding a feature, you should consider deferring.
fantasai: If it's just changing an initial value, then that's a
small-enough change.
tantek: No one supports this today, so it's a new feature.
fantasai: We can add new feature in CR if we need to.
fantasai: We did that for flex.
astearns: We need to determine whether we need to fix this now, or
whether we can defer.
astearns: If it's adding a new value we can defer.
astearns: If we need to change initial value, we can't defer.
tantek: You don't want implementations to shift with new default
value.
fantasai: Leave open for now.
astearns: If we keep open, link is to email.
astearns: We need github issue
astearns: and add to issue whether we need to change initial value.
Florian: This isn't shipping but it's in svg.
astearns: I can see the default value ignore the svg.
fantasai: The whole thing more investigation.
Issue 14: 'text-emphasis' shorthand should not allow only <color>
-----------------------------------------------------------------
fantasai: Two issues are rejected
fantasai: #14
<fantasai> https://drafts.csswg.org/css-text-decor-3/issues-cr-2013#issue-14
fantasai: A request to forbid text emphasis from having only a
color.
fantasai: We already allow this for border, etc.
astearns: Have they responded to rejection?
fantasai: I think he's ok with it but haven't found email.
tantek: I'm missing why we should do this.
tantek: Border color is right answer, we already have this pattern.
RESOLVED: We reject issue 14 but will follow up.
fantasai: tab followed up, there was no response for a year
<tantek> tab's message URL?
<fantasai> https://lists.w3.org/Archives/Public/www-style/2015Nov/0355.html
<tantek> (was not linked from Xidorn's message)
<fantasai> because our archive software is terrible
<tantek> agreed resolve per Tab's response / explanation
Issue 5: text-shadow should apply to inline images
--------------------------------------------------
fantasai: Should text shadow apply to inline images.
<fantasai> https://drafts.csswg.org/css-text-decor-3/issues-cr-2013#issue-5
fantasai: We've had it so long it would break things (issue 5).
astearns: Any objections to the rejection?
RESOLVED: Reject issue 5 and follow up.
Issue 10: Clarify whether emphasis marks are upright or sideways for
sideways-rl/lr
--------------------------------------------------------------------
<fantasai> https://drafts.csswg.org/css-text-decor-3/issues-cr-2013#issue-10
fantasai: Next set of issues:
fantasai: Issue #10.
fantasai: Text emphasis marks go on each char, older than
underline, used in cjk
fantasai: In vertical text they go on R side.
fantasai: We added new mode for vertical, sideways-RL and
sideways-LR.
fantasai: My proposal was to make sideways-* behave as rotated
horizontal text wrt emphasis marks.
fantasai: It's for graphical effects in English, like book titles
or headings.
fantasai: It also rotates cjk chars.
fantasai: It's not a vertical writing mode.
fantasai: Question was what do we do for emphasis marks??
fantasai: If we turn all cjk sideways, we should also turn
emphasis.
fantasai: So koji thinks we should make it undefined, since this
is very rare
fantasai: due to implementation issues--it's easier to do as for
vertical-*
koji: And it's really edge cases.
Florian: I can buy both those arguments
Florian: this is not vertical-rl
Florian: rather than undefined, how about should?
koji: I agree
koji: but most common case of sideways-rl is for non-cjk.
koji: When ckj user tries to typeset English in a CJK document,
they might want upright.
astearns: (Draws) ??
fantasai: They can be comma-shaped things, so the question is does
the shape rotate.
Florian: You might want cjk emphasis to be upright.
Florian: I'm ok with undefined
SteveZ: Would Japanese really like the variable distance between
the emphasis marks?
SteveZ: Is anyone going to use this kind of emphasis on rotated
text?
Florian: Then we should do should instead of undefined
Florian: Japanese emphasis on Latin, I could argue for upright.
SteveZ: I would expect emphasis to be rotated in the example on
the whiteboard.
koji: We're unlikely to do this.
SteveZ: I'd expect to see that in a user interface, in a vertical
tab.
fantasai: I'd expect it to be upright.
astearns: this is VERY edge casey
astearns: I'm usually not OK with undefined
astearns: but I don't care.
astearns: I'm hearing several people OK with undefined.
RESOLVED: undefined on issue #10
SteveZ: Which is a hint to don't do this.
astearns: Or if someone provides good user feedback.
Issue 13: Should emphasis marks use 'font-variant: ruby'?
---------------------------------------------------------
<fantasai> https://drafts.csswg.org/css-text-decor-3/issues-cr-2013#issue-13
fantasai: Next issue is 13.
fantasai: Should emphasis marks use ruby opentype feature?
fantasai: Ken said they should.
fantasai: Does anyone have opinion?
Florian: I agree with the argument.
fantasai: It's an OT feature, so if it's not there nothing happens.
fantasai: When you draw emphasis marks.
fantasai: You take this unicode code point, reduce by 50%, and set
as ruby.
fantasai: UA could use a dedicated font.
fantasai: If you are using a real font, is that you enable OT ruby
feature
fantasai: it will be shrunk down, having extra bulk will work.
myles: Should be like small caps, if anything in run doesn't
support then you should synthesize.
fantasai: You don't synthesize.
myles: I meant disabled.
fantasai: You don't disable
fantasai: you tell font to turn on feature, if it's not there you
do nothing.
astearns: If run of ruby has fallback.
fantasai: It's not ruby, it's emphasis marks.
myles: Oh. I'm on board.
fantasai: You just turn it on. If it doesn't do anything, it
doesn't do anything.
RESOLVED: Go with ken lunde's suggestion
Issues 11 & 19: Improvements to default UA stylesheet suggestions
-----------------------------------------------------------------
<fantasai> https://drafts.csswg.org/css-text-decor-3/issues-cr-2013#issue-11
<fantasai> https://drafts.csswg.org/css-text-decor-3/issues-cr-2013#issue-19
fantasai: Next issues on underline position.
fantasai: Some were fixes to suggested stylesheet for nesting of
languages.
fantasai: So if you put Japanese inside Chinese you'd get wrong
result.
fantasai: So we fixed that so nesting things would work.
fantasai: That's issue 11.
fantasai: 19 is same thing for different rule in stylesheet.
astearns: Any opinions?
astearns: Have we gotten i18n review yet?
fantasai: No, I'll ping r12a
RESOLVED: Accept fixes to handle fixes in default UA stylesheet.
Issue 17: 'text-emphasis-position' requires too many arguments
--------------------------------------------------------------
<fantasai> https://drafts.csswg.org/css-text-decor-3/issues-cr-2013#issue-17
fantasai: Issue 17, syntactic.
fantasai: Takes two keywords, one for horizontal and one for
vertical.
fantasai: Nakamura Momdo says too wordy.
fantasai: We just want to change in horizontal.
fantasai: Can you make it easier to use one keyword.
fantasai: The languages that use this feature usually have same
opinion on which side.
fantasai: If you want to change you should mention horizontal.
fantasai: Suggestion is to make vertical component of
text-emphasis-position to be optional.
fantasai: There's an email to explain:
<fantasai> https://lists.w3.org/Archives/Public/www-style/2016Dec/0118.html
SteveZ: If you set one it won't change the other.
fantasai: Based on assumption that C and J prefer emphasis on the
right.
fantasai: Which can be checked by i18n.
koji: Why do we have left?
fantasai: I don't know.
SteveZ: If you double mark, you can get emphasis on both sides.
Florian: Like nesting emphasis.
SteveZ: That's more likely.
steveZ: I've seen examples with emphasis on both sides.
fantasai: This is inherited property; never has both.
Florian: So we can't do that.
Florian: So we don't need left.
Florian: Maybe right and both and not right and left.
SteveZ: Can we ask if there's a case for left during i18n review?
ACTION: fantasai to ask about case for left in i18n review
<trackbot> Created ACTION-810
astearns: Any objections to simplifying argument for
text-emphasis-position?
RESOLVED: text-emphasis-position: [ over | under ] && [ right |
left ]?
<skk> I think the position of emphasis should be explored. I saw
some cases that only left emphasis. If I misunderstood,
sorry.
<astearns> skk - that's the action on Fantasai - to look into only
left or both in vertical text
<skk> astearns, thanks for letting me know.
Issue 20: Update spec to handle sideways-lr/sideways-rl
-------------------------------------------------------
<fantasai> https://drafts.csswg.org/css-text-decor-3/issues-cr-2013#issue-20
<fantasai> https://lists.w3.org/Archives/Public/www-style/2016Dec/0119.html
fantasai: Issue 20, adding sideways-rl and sideways-lr
fantasai: Introduced typographic modes, same as rotated horizontal
text.
fantasai: It will follow the horizontal settings for the text.
fantasai: Any comments?
RESOLVED: Update.
Issue 18: 'text-underline-position' should default to 'auto' for CJK,
to avoid compat issues
---------------------------------------------------------------------
<fantasai> https://drafts.csswg.org/css-text-decor-3/issues-cr-2013#issue-18
fantasai: Issue 18.
fantasai: Suggested UA rules for cjk used "under":
fantasai: for Japanese right and under
fantasai: for Chinese left and under.
fantasai: We set the underline position for horizontal text as well
fantasai: but that changes browser behavior.
fantasai: Changed auto to under
fantasai: but was changing things.
fantasai: So I changed default user stylesheet
fantasai: to minimize changes from current behavior.
fantasai: This is important for Latin text inside cjk but didn't
tag Latin text
Florian: Which is common.
fantasai: To avoid regression.
fantasai: 2 changes: one to default UA stylesheet, other is to
change omitted behavior for text-underline-position.
fantasai: Assuming no objections to changing UA stylesheet.
fantasai: You can always be more explicit.
astearns: Is there any benefit to have text underline position
behave like text emphasis position?
astearns: Where we don't allow only setting to right?
fantasai: Text underline position allows auto or under
fantasai: You don't ever do underlines on over side in horizontal
text,
fantasai: otherwise you'd use an overline.
fantasai: So it's a bit different.
astearns: Seems ok to have omitted value default to auto. What
does it do now?
fantasai: Defaults to under.
RESOLVED: Omitted value defaults to auto.
Issue 1: Allow UA to skip ink by default/Issue 22: CJK doesn't like
skipping ink, shouldn't by default
-------------------------------------------------------------------
fantasai: issue 1
<fantasai> https://drafts.csswg.org/css-text-decor-3/issues-cr-2013#issue-1
<fantasai> https://github.com/w3c/csswg-drafts/issues/727
fantasai: Allow UA to skip ink by default
Florian: Do we need to discuss with issue 22?
<fantasai> https://drafts.csswg.org/css-text-decor-3/issues-cr-2013#issue-22
<fantasai> https://github.com/w3c/csswg-drafts/issues/727
<fantasai> https://github.com/w3c/csswg-drafts/issues/707
koji: There are a few related issues:
koji: Our goal... blink has implemented skip ink, it's currently
opt in.
koji: We want it on by default.
koji: When get more implementations better to have on by default.
koji: In doing so...
koji: Currently value is part of text decoration skip ink.
koji: There are side effects.
fantasai: When you want to turn on ink skipping
fantasai: it resets other things you might skip, like spaces.
fantasai: Whether you skip ink can be language dependent
fantasai: and a different question than skipping images.
Florian: The language dependent part is tricky.
Florian: We've talked of cjk and Arabic.
Florian: In cjk you don't want ink skipping often.
Florian: It's unclear in Arabic.
Florian: May be influenced by position of underline.
Florian: In cjk if you do it bad you may overlap bottom of cjk
chars, which is bad
Florian: might interfere with accents in Arabic
Florian: but with better positioning data it's ok.
Florian: Maybe we need auto.
koji: Skip ink is different from others, take ink out from skip.
Florian: It's an overlapping issue.
koji: If we agree ink is different, and take it out from skip
Florian: If we take ink out, it makes the other issues less severe
but they don't go away.
Florian: The ink-skip property is a list of on-off toggles, which
cascades poorly
Florian: because it's a bunch of flags, if we want to add more.
Florian: The explicit things that authors already written mean new
flags are overwritten unintentionally
Florian: and if we want different defaults in different browsers.
Florian: We should be inspired by pattern of font variant
Florian: and have a separate property for every one.
Florian: So ink could have on/off/auto
Florian: So if you change an edge one, it defaults and cascades
properly.
astearns: If we make all of this into longhands
astearns: people using longhands will short-circuit new values.
Florian: Just have the resets on the shorthands, for everything
else go to longhands.
astearns: Is the ink property the only one that is language
dependent.
fantasai: Edge is also language dependent.
frenemy: In our implementations, we'll store each of these
separately.
astearns: It's harder to author, 'cause setting five different
things.
Florian: Most of the time you're thinking about one thing:
<Florian> text-decoration-skip: none | auto
<Florian> text-decoration-skip-objects: none | all
<Florian> text-decoration-skip-spaces: none | [leading ||
trailing] | all
<Florian> text-decoration-skip-ink: none | all | auto
<Florian> text-decoration-skip-edges: none | all
<Florian> text-decoration-skip-box-decoration: none | all
koji: More comfortable not to have shorthand
koji: unlikely to set all of them.
astearns: Is there use case for reset for everything?
fantasai: You'd need text-decoration-skip: none
fantasai: There was a way to say "don't underline me".
Florian: None is skip nothing, not everything.
fantasai: Maybe that was dropped along the way.
Florian: The way to skip is to use objects and turn to inline box.
astearns: I like the proposal for separate properties.
astearns: Does anyone object?
Florian: The one I put on IRC has auto for ink-skipping.
Florian: We haven't decided whether that should have an auto
Florian: and the leading/trailing we've resolved to add to level 4.
astearns: Any objection to the explosion of skipping properties?
fantasai: I'm ok on principle
RESOLVED: Add all of the skipping properties.
<break duration="15minutes">
text-decoration-skip shorthand
------------------------------
Florian: What we agreed during the break is
Florian: having in the shorthand having on/off flags based on
presence of keywords is bad.
astearns: Do we have a shorthand with longhand-on longhand off
anywhere else in css?
Florian: font-variant is not on/off but A/B
Florian: we're not sure about none value in shorthand.
Florian: Current version of expanded longhand is bad
Florian: for level 3 have shorthand with just initial.
fantasai: What about auto?
Florian: We can't defer removing things.
Florian: So shorthand just has initial reset, possibly named auto.
fantasai: What's implementation status?
(mostly not implemented, except for ink)
astearns: You're proposing to take the whole feature to level 4?
fantasai: Yes.
fantasai: If we need that switch we can have that switch.
fantasai: I'm saying remove all author control over ink skipping
in level 3; leave it up to the UA explicitly.
eae: I think there's value in giving authors control.
Florian: I don't have strong opinion on level 3 vs 4.
jensimmons: I don't have opinion on level.
jensimmons: Authors want ways to control underlining; the sooner
the better.
jensimmons: As soon as people learn about this they're going to
want this.
jensimmons: They want skipping behavior.
fantasai: Putting them together makes sense.
myles: Web authors don't care about levels.
fantasai: If we're redesigning the world, we should put this into
a new level.
fantasai: We need to figure out what we need and how to make it
easy to use.
fantasai: Thickness etc are in level 4 'cause they're new
fantasai: and it will be a package.
jensimmons: I agree it makes sense to ship as whole.
dbaron: It feels like ink skipping the most popular thing in whole
spec, based on 15 years of feedback.
fantasai: There's an argument it should be on by default
fantasai: so if we have on by default, we can push control to next
level.
Florian: There are i18n concerns.
frenemy: Most of other properties I'm ok with another level, but
want control for skipping.
frenemy: ink skipping: yes or no should be in level 3.
astearns: That would be a proposal to leave ink in current level,
and move everything else + shorthand to next level.
Florian: ok with me
Florian: but want to move simplified shorthand to next level.
Florian: In level 3, have text-decoration-skip-ink: yes/no/auto/,
level 4 has longhands and other values. start with
minimal.
astearns: Is this ok, koji?
koji: Yes.
tantek: My concern is with sweet spot of what authors not.
jensimmons: Skipping ink alone is good.
RESOLVED: text-decoration-skip-ink in L3, other skipping controls
in L4
<fantasai> Text Decoration 4: https://drafts.csswg.org/css-text-decor-4/
Skipping ink vs. underline position
-----------------------------------
<fantasai> https://lists.w3.org/Archives/Public/www-style/2015Feb/0336.html
fantasai: Should position of underline depend on what we're
skipping?
Florian: If you're skipping spaces, and you have a space in a
different font, do you want to move the underline so you
go under the big space.
astearns: Let's have this as issue on level 4.
fantasai: Yes.
<tantek> yes.<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:20:31 UTC