- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 03 Jul 2013 14:08:08 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- krit requests review of CSSMatrix interface for FPWD
https://dvcs.w3.org/hg/FXTF/raw-file/tip/matrix/index.html
- RESOLVED: text-combine compression is UA-defined, however UAs
MUST transform full-width chars/glyphs before
compressing them. Spec will include jdaggett's sample
algorithm as an example for UAs to follow.
- RESOLVED: text-decoration line thickness and position undefined in L3
(replaces previous resolution at Tokyo F2F)
- RESOLVED: undefined in L3 whether text and decorations are composited
before shadowing or not
- RESOLVED: Drop text-underline-position: alphabetic
- RESOLVED: Take CSS3 Text Decoration to CR
====== Full minutes below ======
Present:
Glenn Adams
Tab Atkins
David Baron
Justin Erenkrantz
Elika Etemad
Simon Fraser
Daniel Glazman
Dael Jackson
Koji Ishii
Peter Linss
Edward O'Connor (late)
Anton Prowse
Florian Rivoal
Simon Sapin
Dirk Schulze
Leif Arne Storset
Nick Van den Bleeken
Lea Verou
Steve Zilles
Agenda: http://lists.w3.org/Archives/Public/www-style/2013Jul/0061.html
<RRSAgent> logging to http://www.w3.org/2013/07/03-css-irc
Scribe: SimonSapin
CSSMatrix review
----------------
<krit> https://dvcs.w3.org/hg/FXTF/raw-file/tip/matrix/index.html
krit: SVGMatrix is 2D. With transforms, we need 3D
krit: discussed having a CSSMatrix interface, unified between specs
krit: asking for FPWD. Concerns/discussion to the ML
CSS3 Text
---------
plinss: follow up on text-align-last
fantasai: Rossen is not on the call, defer
CSS3 Writing Modes
------------------
fantasai: ML discussion with jdagget
fantasai: jdaggett’s proposal for exact rules of resizing. Spec says UA-defined
fantasai: Propose to put his algo as an example, and examples of things
that could go wrong
fantasai: but leave normative text as UA-defined, leave leeway
fantasai: UA could give better results than this exact algorithm
fantasai: Koji and I want to allow better results
fantasai: Want to make sure it’s at least "good". Think having an example
algo is a good way to do that.
florian: how to add controls in future levels on UA-defined behavior?
fantasai: Plan is to have a text-compression mode switch, where the
default is 'auto'
florian: some switches might match auto in some UAs
fantasai: yes
florian: worried about "do what you want auto", if one UA is dominant,
hopefully it’s not too broken
florian: content will depend on the de-facto meaning of auto
fantasai: seems unlikely
fantasai: if we have an example in the spec, most UAs will follow that
unless they try to do better
fantasai: example is not complicated
florian: would be nice to have tests for this non-normative description
fantasai: We can have "may" tests.
fantasai: tests specific to OpenType, specific fonts
fantasai: If the spec has clear examples, implementations will follow
that better than a normative generalization in the spec.
SteveZ: concern: dealing with 2 things. auto is used to do the right
thing for the normal case, bunch of features separately
SteveZ: example: full-size latin letter different than latin letters,
without markup
SteveZ: there, clear algorithm
SteveZ: here, auto is you can do possibly better than this
SteveZ: different use of auto, usually it means something specific, not
do something UA-dependent.
SteveZ: not sure you really want 'auto'
fantasai: it is automagic
SteveZ: users complain without the magic
SteveZ: people want to do what the users expect
SteveZ: to way to have this is normative text and test cases
SteveZ: examples are nice but … we trip over automagic
fantasai: I don’t expect lock-in in this case
fantasai: If you do a good job, no need to match against anything else.
fantasai: If it looks bad, author will just not use the feature there.
fantasai: There's no way to tweak the resulting layout for one implementation.
fantasai: You either enable it or don't.
fantasai: no effect on the rest of the layout
SteveZ: still uncomfortable about undefined automagic
koji: discussing rendering quality, doesn’t matter much
florian: little uncomfortable, but can go with this
plinss: jdaggett seems to have concerns with this. Can you summarize?
fantasai: He’s concerned that implementations will do worse because
normatively, it's allowed.
fantasai: We'll add examples of "don’t do this"
plinss: Normative restrictions? "Can do better, but don’t do this"
fantasai: I'm ok with that.
florian: limited normative requirements
plinss: problem is defining "better"
[...]
plinss: objections?
fantasai: proposal is: normative prose says "UA-defined how the compression
happens, but must transform full-width to half-width or proportional
before compression"
fantasai: then add jdaggett's example algo
fantasai: and suggestions to do better
fantasai: This requires transforming at least full-width.
fantasai: and we have an example of what people expect.
fantasai: a UA can do simpler--e.g. only graphic compression, no glyph
substitutions
fantasai; Or can do smarter--e.g. dealing with cases where glyphs are only
partly missing--
fantasai: But normatively require don’t do this, that looks bad.
RESOLVED: accepted the above proposal
CSS3 Text Decoration
--------------------
plinss: issue: making line positioning undefined
fantasai: discussed at F2F
fantasai: CSS21 says "position and thickness is undefined. May consider
font info of the descendant that you are underlining, but not
required. But must have one non-broken line"
fantasai: 2 interpretations of "on one line"
fantasai: either way, allowed to consider the descedants
fantasai: in L3, we tightened up the prose --
fantasai: Aryeh had raised a concern when strike-through doesn’t go
through the text, e.g. if striking through element contains
element sizing the font larger.
fantasai: spec says how to calculate, what to consider or not,
eg. skip vertical-align'd content
fantasai: dbaron against. Says it's complicated, and concerned that e.g.
a bunch of links that should be the same, if one contains some
subscript, its underline will be offset from the others by a
a few px.
fantasai: F2F proposal was to just use the underlining element's settings.
fantasai: But this works poorly for Aryeh's case
fantasai: And it's really bad if you don't align to alphabetic baseline
fantasai: e.g. in vertical text, default is to use central baseline
fantasai: underline can cut through the text, when element contains text
that's bigger
fantasai: I think this is worse than a few px off
fantasai: don’t want to require this behavior in CSS
fantasai: underline should be on one side of the text alway IMO, not cut
through it
fantasai: For this level, no consensus on exactly what we want, so propose
to leave undefined like 2.1
fantasai: Deal with it in L4.
dbaron: fine with me, with explanation why
fantasai: ok, specifics?
dbaron: the two rationales that you just said
plinss: opinions?
RESOLVED: text-decoration line thickness and position undefined in L3
<SteveZ> What can we do to resolve this in Level 4
fantasai: 2 more issues
fantasai: shadows. Text underlined, separate shadow? Or composite together
and shadow that?
fantasai: Looks different with semi-transparant shadow color.
fantasai: I think we want the shadow to be drawn at once, combined
dbaron: that’s a lot more impl. work
dbaron: I don’t know that we define it for overlapping glyphs, but
should be the same
smfr: Within the same text run, one shadow
smfr: accross spans maybe not
smfr: for the underline, looks nicer if painted as one
leaverou: I think composited shadows make more sense, but can also be
achieved with filters
dbaron: I think this should be left undefined at this level
fantasai: ok with that
leaverou: what do browsers do?
dbaron: (missed)
leaverou: what if letters overlap?
dbaron: not sure, depends on whether they have the same font
leaverou: overlapping letters are more important, authors do that with
negative letter-spacing
florian: how expensive is it? maybe only composit if necessary?
dbaron: don’t know
fantasai: text-decoration always overlaps text … ok maybe not
dbaron: sort of decision where the group makes a resolution that
requires impl. to throw out code and start again
dbaron: needs more consideration that 3 min on a telecon
dbaron: should research what impl. do
<SteveZ> +1 for David's point
dbaron: if we have interop on one thing and add "should" on something
else, are we ever gonna get it?
dbaron: If there's a should, then it encourages implementations to work
towards that. If we already have interop on the opposite, then
it encourages *less* interop.
Rossen: Anyone have a quick test case?
krit: need images from different browsers
SteveZ: how soon do we need an answer?
SteveZ: leave it undefined at the moment, and come back later
SteveZ: what does Illustrator do?
krit: have to check
SteveZ: need testing before deciding anything
<leaverou> very quick testcase I just made: http://dabblet.com/gist/5920266
<dbaron> leaverou, you should also try (a) mixed LTR and RTL text within
the same element and (b) an element boundary with a color change
(c) an element boundary without a color change
<leaverou> yes dbaron, it was a one minute thing :)
<krit> SteveZ, you can just specify shadow on the text group in illustrator
plinss: do we want to go to CR or wait on this?
SteveZ: can we add "should" and mark it at-risk?
florian: typically not at-risk for changing our minds, rather for lack
of impl
florian: if we put the should, it encourages ppl to follow it. If we
have interop, it’s bad to break it
SteveZ: can we get research by next week?
leaverou: looks like every browser overlaps ???
florian: old Opera makes the overlapped letters darker
dbaron: Gecko on Linux does not overlap
dbaron: might depend on platform-specific text rendering
florian: Presto doing it wrong, but not relevant anymore
Scribe: fantasai
plinss: path forward?
plinss: leave it undefined?
smfr: think we have to leave it undefined
fantasai: works for me
rossen: it's ok
plinss: ok, undefined in L3
RESOLVED: undefined in L3 whether text and decorations are composited
before shadowing or not
<dbaron> http://dev.w3.org/csswg/css-text-decor-3/issues-lc-2013#issue-6
<koji> http://lists.w3.org/Archives/Public/www-style/2013May/0139.html
fantasai: dbaron raised an issue on whether alphabetic is needed for
text-underline-position. I don't know, so have no oinion.
dbaron: who thinks it is necessary?
szilles: my response is, what are we objecting to in alphabetic?
dbaron: Wasn't clear to me how to implement this stuff
dbaron: or which value matched existing implementations
dbaron: also there's issues with using font metrics for underlining
dbaron: if you use the underlining metrics from the font, which value
of text-underline-position is it?
dbaron: if you have a CJK font, which underline are you using?
szilles: CJK fonts usually have two sets of metrics
szilles: You can choose the dominant baseline in a table based
fantasai: I thought fonts had various baselines, but only one underline
position metric
szilles: you may be right. I think in CJK fonts, underlines are lower
than alphabetic, because CJK characters descend lower than
alphabetic baseline
szilles: feedback from Adobe Typography was, use the font baseline if
it's there.
dbaron: So question then is, which value in CSS spec corresponds to use
the font metrics?
dbaron: My problem with this spec is, it's hard for me to understand
how to implement
szilles: I understand. Happy to work with fantasai to fix that.
koji: spec says alphabetic is based on font emtrics
fantasai: [describes original intention of values, which had nothing to do
with whether to use font metrics]
fantasai: intention of alphabetic was "put the line near the alphabetic
baseline"; intention of "under" was "put the line under the text"
fantasai: If you're ignoring font metrics, spec is very simple to implement.
fantasai: If you're using font metrics, then have problem that fonts aren't
clear on what their metrics represent
fantasai: Because some fonts think the underline metric represents the
alphabetic position, and others think it represents the
accounting position.
fantasai: Webkit, for example, doesn't use font metrics. Just picks a
position below the alphabetic line.
szilles: bad typography
szilles: [... some issue of font metrics ...]
szilles: So dbaron's point was, how do I implement what's there?
dbaron: Part of reason to drop alphabetic is that there's nothing left
in spec that's unclear.
szilles: But doesn't auto ask for alphabetic position?
szilles: I'm not attached to alphabetic value, want auto to do something
reasonable
dbaron: auto is vague enough that we can just keep our current implementation
florian: Is it bad to disallow looking at font metrics for non-auto values?
szilles: Yes, that is bad.
dbaron: also, what is the use case for alphabetic?
szilles: seems to be same as auto
dbaron: for the cases where you would want it, at least
szilles: So, you're reasonably happy with current definition of auto
szilles: ...
dbaron: alphabetic is same thing as auto in cases where you want it,
but also unclear how to use font metrics
fantasai: Current spec has blanket statement for using font metrics
wherever appropriate
szilles: Can we come up with a definition of appropriate?
fantasai: Don't really want to do that...
fantasai: "appropriate" allows, e.g. blacklisting metrics of bad fonts,
which Gecko does currently
(don't want to e.g. try to spec the backlist)
fantasai: Maybe drop alphabetic, and tackle that in L4 if someone wants
to define it for OpenType.
plinss: What does it mean for vertical text
fantasai: vertical text has an alphabetic baseline; should be defined
in writing modes (if not, bug in writing modes)
fantasai: text decoration spec is in terms of over/under (relative)
directions, so no issue here
szilles: should auto do the right thing in vertical text?
fantasai: Interesting question. If you have sideways Latin in vertical
orientation, want the underline to look just like in horiziontal
text
fantasai: but if typeset upright, want to shift it over
fantasai: similar problem to CJK in horizontal, want to make sure it
shifts down enough
fantasai: so maybe add examples to the spec showing things UA needs to
consider...
plinss: So, do we want to drop alphabetic?
fantasai: think so
szilles: now that I understand dbaron's issues, makes sense to me
RESOLVED: Drop alphabetic
plinss: Move to CR?
fantasai: Have to make edits, but that does close all the issues
fantasai: Will probably take a month and a half to schedule CR telecon,
so can go ahead with that and have edits done by then. :)
...
szilles: My understanding of our decisions today was, take conservative
approach, don't define anything new
fantasai: Yep, so no need for another LC
RESOLVED: Take CSS3 Text Decoration to CR
Received on Wednesday, 3 July 2013 21:08:36 UTC