- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 21 Nov 2013 18:29:46 -0500
- To: www-style@w3.org
Box Generation and Elements as Regions
--------------------------------------
- RESOLVED: Closing issue in bug 15733.
CSS Writing Modes, Tr Fallback
------------------------------
- Koji discussed the ongoing issue about how Tr should fallback,
rotated or upright.
- Another solution was also raised to leave the fallback behavior
undefined or must not.
- RESOLVED: Accepting option A, "If the vert alt glyph is not
present in the font, UA may, but is not expected to, substitute
the glyph," with term "MAY WISH TO" and referencing RFC6919.
- RESOLVED: Take CSS Writing Modes to Last Call.
=====FULL MINUTES BELOW======
Present:
Rossen Anatassov
Tab Atkins (IRC Only)
David Baron
Bert Bos
Elika Etemad
Sylvain Galineau
Daniel Glazman (IRC Only)
Rebecca Hauck
Israel Hilerio
Koji Ishii
Dean Jackson
Taichi Kawabata
Jirka Kosek
Chris Lilley
Peter Linss
Larry McLister
Simon Pieters
Simon Sapin
Dirk Schultze
Leif Arne Storset
Alan Stearns
Lea Verou
Jet Villegas
Kazutaka Yamamoto
Steve Zilles
Agenda: http://wiki.csswg.org/planning/tpac-2013#agenda
Box generation and elements as regions
--------------------------------------
ScribeNick: dbaron
[projector and microphone configuration]
[astearns shows http://www.theguardian.com/world?view=mobile]
astearns: I wanted to describe a few things we're doing with regions.
astearns: We're pushing for using regions and named flows in
responsive UI designs.
astearns: I'm showing a site from the guardian, not using regions at
all. It has a navigation bar at top, with a menu that comes
out. It's assuming for a landscape tablet display. As you
narrow the display, the navigation elements move to the
menu.
astearns: The script is putting items that don't fit in the width and
moves elements around in the DOM.
astearns: The script is a little buggy and janky.
astearns: It's really easy to do by defining navigation elements as
belonging to a named flow, two regions: nav bar, and menu.
astearns: That's much more performant, and doesn't need script.
astearns: A similar thing, the example at
http://adobe-webplatform.github.io/regions-adaptive/
astearns: You don't want these buttons to show up on mobile, so at a
certain width all the buttons get collected into a named
flow and put into a slide-out.
astearns: Again, no script, just a media query that turns on the named
flow.
astearns: I just wanted to introduce these ideas to the group.
astearns: In this case it's a region chain of regions all with a
particular height (viewport height) so the content is
interspersed with images:
(http://adobe-webplatform.github.io/Demo-for-National-Geographic-Orphan-Elephants/
)
astearns: I've been posting to www-style about how named flows work
with overflow:fragments in an attempt to convince people
that the issue in regions about box generation should be
closed because every box generation mechanism we have
defined or proposed for CSS is something regions can
participate in.
astearns: The original issue was put into the specification because
people wanted to see what the page template proposal that we
had only talked about would look like.
astearns: I produced the page template proposal where we can target
CSS-generated boxes with region chains.
astearns: I assume we're going to do something similar in future work
with this group. Regions works well with that.
astearns: Introduced before and after elements, and introduced
overflow:fragments which dbaron ran with and produced an
interesting spec; but again, regions works well with
overflow:fragments.
astearns: You can take two overflow:fragments elements in your
document, link them with named flow, and have content
flowing through elements without adding region elements to
markup at all.
astearns: So the question was, do we need a box generation mechanism
for regions, and I've maintained all along that we don't,
and we'll use every box generation mechanism we have for
CSS.
astearns: So unless anybody has an objection I'd like to close that
one particular issue.
dbaron: I'm ok with closing 15733.
fantasai: 16858 stays open.
astearns: Yeah.
RESOLVED: closing issue in bug 15733
astearns: I don't know that it's going to be fruitful to talk about
elements today. I've been posting to the list; it's on
dbaron's todo list to look at those messages.
astearns: If anyone wanted to discuss what we've been talking about on
the list about using named flows and region chains as lower
level mechanism for describing fragmentation and pagination
and things, we can but I'm also happy continuing discussion
on list.
astearns: Anybody want to talk about that right now?
astearns: If not, we can move on to next agenda item.
CSS Writing modes, Tr fallback
------------------------------
Plinss: Maybe we can close this one today?
[Koji projects http://www.unicode.org/reports/tr50/]
Koji: The issue is Tr fallback in writing-modes.
Koji: Some background on the discussion:
Koji: UTR50 describes 4 values (shows Table 1). One of them is Tr. T
means transform, not only about upright or rotated, but usually
requires different type of transformation.
Koji: Tr means if font doesn't provide alternative glyphs it should
fall back to rotated.
Koji: Tr has 2 purposes (1) for backwards compat -- but all existing
fonts have alternative glyphs.
Koji: (2) example is is U+3030 WAVY DASH - not only about rotation but
also includes flipping.
<fantasai> For backwards compat -- you can see, these characters are
not transformed, just rotated, but since all fonts contain
transformed glyhs that perform the rotation, want to use
those glyphs.
Koji: The recommendation is a preference for flipping in font system,
but preference to fall back to rotated fonts.
Koji: In CSS writing modes, we had same definition for Tr at one point
Koji: 1.5 years ago John (Daggett) proposed that implementation cost
of Tr fallback is high, and the number of characters affected is
about 10-20 characters.
Koji: Given the definition -- if font provides all alternative glyphs
for these 20 codepoints, these issues will go away.
Koji: John said that even though UTR50 defines fallback, given
implementation cost, he wants CSS to define fallback to upright.
* sgalineau does not believe jdaggett described the cost as sky-high
or 'impossible'. His argument was that it was unnecessary.
Koji: After that we had 2 different feedbacks from developers, saying
implementation is easy, and they want their UA to display those
characters correctly, even with existing fonts.
Koji: So we have a situation where 2 developers want fallback to
rotated and 1 to upright.
Koji: fantasai and I discussed it and considered 5-10 characters as
subtle difference.
Koji: We agreed to define UA may fall back to upright or sideways,
which is what we have in spec right now.
Koji: In September John raised a concern that 2 options can cause
confusion to authors, and fallback to rotated is wrong or the
cost is high.
Koji: So John wants CSS to define "must upright."
Koji: So sylvain agreed with that; glenn disagrees and wants rotated
or both options.
Koji: James Clark is ???, fantasai and Rossen are opposed to it.
Koji: Eric said he agrees with John 2 weeks ago.
Koji: I talked with Eric last week during UTC; he still wants upright,
but ok for WG to resolve.
<sgalineau> For Adobe, Eric Muller believes the best option is to
mandate no fallback
http://lists.w3.org/Archives/Public/public-i18n-cjk/2013OctDec/0036.html
Koji: I think that's pretty much situation up to today.
Koji: This issue is last issue remaining for LC of css-writing-modes.
SteveZ: 2 comments:
SteveZ: (1) You said TR50 said "should fallback" but what said is "can
fallback", though that's a nit-pick.
SteveZ: (2) Second point, what Eric was concerned about was telling
whether font had the appropriate characters. He's concerned
about looking at font data because with font subsetting you
may get false information about what the font is doing if
you're getting a subset. So he was concerned about building
that particular piece.
SteveZ: (3) John's point was that whenever we have optional sorts of
things, it means implementations diverge and users get
unhappy.
Koji: My comments on those three:
Koji: (1) As you said it's "can".
Koji: And, as Eric said, this UTR50 is informative, so it's not
forcing everything.
Koji: (2) So I understand that not only it has some other issues like
John pointed out, may break dlig.
Koji: The argument is that can be fixed by designing fonts correctly
or designing embedding correctly.
Koji: So there are challenges,
Koji: But that's not something really not possible.
Koji: (3) There may be a ??? on UTR50,
Koji: But the original goal of UTR50 was to provide consistent
orientation.
Koji: During the development phase we figured it's not possible with
existing fonts,
Koji: So our goal was to give best consistency, and complete
consistency if UTR50 compatible font is used,
Koji: And there are 10 characters we are discussing for Tr,
Koji: And 20 or more that will be inconsistent anyway.
Koji: I'm working with Japanese publishers and AntennaHouse about how
authors have to be careful when authoring to be careful
orientation is consistent across existing fonts.
Koji: I agree that allowing both options can diverge and add more
burden to authors, but it's not something we can really avoid.
Koji: Given the cost; development cost varies depending on
architecture.
Koji: Given that we can't reach consensus I think allowing both is
best option.
SteveZ: I'm concerned about something you said: fixing a rare case and
fixing it at the cost of putting burden on anyone who develops
font subsetting.
SteveZ: Font subsetting seems likely to be very popular for East Asian
fonts. Adding cost to that to fix this problem seems wrong way
to go.
fantasai: I don't see what this has to do with subsetting.
SteveZ: Probably not in this case... either character is there or not
Koji: Let me explain: Tr defines render as upright, but if no vertical
alternate, fallback to rotated.
Koji: Font subsetting could only subset one glyph without the vertical
table.
Koji: In that case, using the subsetted font, UA cannot determine if
codepoint has a vertical alternate glyph or not.
SteveZ: Yes, that sounds correct.
Koji: The case for PDF, but is for epub or html where user can
override writing modes for usability/accessibility, regardless
of this issue, font subsetting should include both horizontal
and vertical alternate glyphs into the subsetted fonts. If they
do that they also solve this problem.
Koji: It's true that it requires an additional step, but it's not only
to solve this problem.
Koji: Does that answer your questions?
SteveZ: I certainly understand what you're saying; the requirement for
not subsetting with only one of directional things is not
coming from this but coming from that user style sheets could
override, so you need that capability anyway.
Koji: This is about 10 characters. In John's original proposal those
10 characters will be rendered incorrectly for some existing
fonts.
Koji: John and Eric think that's ok because they're rarely used
characters ...
Sylvain: No, they think fonts will get fixed.
Koji: I know there are technical differences... if it's about subtle
differences why do we care so much?
SteveZ: I understand last way, but it applies equally way to any
resolution.
Koji: Thus I ask for it to be either behavior. John wants to demand
single behavior, I want to know why.
Jet: The cost to every other codepoint that's not those 10,
Jet: Extra conditional in code -- vs benefit to rendering those
characters incorrectly.
Sylvain: I posted a link to Eric Muller's post. Eric thinks no
fallback is the better decision.
Sylvain: That's consistent with feedback I got from other experts.
Sylvain: I think the issue about cost was not about absolute cost, but
about cost relative to how often it's needed, since
expectation is that fonts will be fixed.
Sylvain: In general, in standards providing optional behavior is a
source of incompatibility.
Sylvain: I think that makes sense.
Koji: It costs more for one option for one architecture but opposite
cost for other architectures.
Koji: So if we mandate one we have to pick one.
Sylvain: That's the point of mandating.
Koji: It costs more for some browsers and less for others.
Sylvain: I don't think having no fallback can cost more than fallback.
Koji: I disagree.
Koji: 1.5 years ago the discussion, one said cost is sky high, another
developer said cost is low, another developer said cost is
opposite.
Sylvain: You write complex fallback code that you have to test for
something that will happen extremely rarely. That's not sky
high in terms of total amount; it's relative to the benefit.
Sylvain: Mandating no fallback will lead fonts to update. (?)
Sylvain: So that code will never be used.
Plinss: Does the practice of subsetting potentially break that
argument?
Plinss: If alternates end up not part of the subset, not guaranteed to
have them.
<SimonSapin> If we assume fonts will get fixed, can we also assume
subsetting tools will get fixed?
SteveZ: Koji's point was that subsetting for CSS requires both glyphs
to be there because you don't know what will be there until
things arrive. You can always do it wrong, but then people
will get bad results and people will stop using your system.
Rossen: What if we, instead of disallowing it, discourage it?
Rossen: We can say that behavior is not expected, but if there's an
implementation that really wants to do it, it's at least not
forbidden?
Rossen: Authors reading spec should not expect it to be supported, but
they are not restricted to forbid behavior.
fantasai: I think another thing to consider would be font formats
other than OpenType.
fantasai: In OpenType a number of these characters are transformed by
convention, but this might not be true in another font
format might have different expectations.
fantasai: So even if we want to mandate this for OpenType I don't
think it would make sense to mandate for all font formats.
fantasai: Also it doesn't make sense ... ??? if handled at font engine
level rather than text layout level.
SteveZ: Rossen, if I understood you: "If the data for the rotated form
is not present, this specification does not define what should
be done"?
fantasai: That works for me.
Rossen: That's more of the undefined case.
SteveZ: I think advantage of undefined, it still leaves the forcing
function of getting the fonts updated, because you don't know
what's going to happen.
Rossen: Would anyone not be able to live with undefined?
r12a: Would it be a question of leaving it undefined like that, or
undefined plus recommend that you follow UTR50?
fantasai: The wording I'd suggest is that it's undefined whether the
UA is allowed to synthesize some kind of substitute glyph.
dbaron: So no longer Rossen's "undefined but discouraged" proposal?
<dbaron>: I'd prefer undefined but discouraged over simply undefined.
SteveZ: Where are we?
Rossen: I think between disallowed and undefined?
Rossen: As I understand, John wants disallowed.
<sgalineau> fwiw feedback on fallback implementation cost I have
heard: cheap to hack it, more expensive to do it right.
Too expensive for the number of cases that will exercise
it.
<fantasai> "UA may but is not expected to synthesize the substitute
glyph"?
Rossen: If we say UAs are not expected to support rotated sideways
glyph, but not required not to, then that should be a way of
saying basically: don't expect it to work, but implementations
might do it.
ChrisL: Or in other words would be saying "you may fall back but not
required to" just like UTR50 says.
SteveZ: That's why I'd prefer it's simply undefined, since otherwise
you're back out of undefined.
[various people mumbling]
Bert: That's the wrong way round, I'd say.
Rosssen: Current spec says UA may, but not required to fall back to.
Rossen: The current statement is close.
Bert: The current statement suggests that what UTR50 says is that
rotating better than not.
Bert: The want implementations to rotate but we still like them to do
it.
Bert: I think wording should be clear that we still want them to.
dbaron: I think many people here disagree that we want them to.
dbaron: People think we're better off expecting font to have correct
data in it, instead of adding features to work around bugs in
a font.
<sgalineau> +1 to dbaron
Bert: That assumes it's a bug in the font, maybe it's not.
<fantasai> I think for OpenType it would be considered a bug in the
font, but for other font formats might not be...
Plinss: In general I'm ok with any of these proposals.
Plinss: I'm concerned that I don't want us to say "you must not do
this" because if you have a font engine that does this then
the UA has to undo what the font engine is doing.
Plinss: Just saying it's undefined because it is defined in UTR50,
Plinss: If we're explicitly undefining it then we're just sanctioning
what UTR50 says.
<fantasai> +1 to Peter
<fantasai> wrt undoing font engine
Plinss: So if we have an explicit preference we'd ???
Plinss: I have concerns if we're willfully violating another spec, if
it says "can do it" and we say "must not do it."
<Rossen_> "the UA is not expected to fallback..."
fantasai: Can we straw poll on wording "may, but is not expected to"?
Plinss: Should we reference April 1 update to RFC2119?
fantasai: ?
Rossen: What if we say UA is not expected to do fallback?
fantasai: We have to say allowed disallowed or optional.
fantasai: We have to say, normatively, what is it.
fantasai: Saying something is expected or not expected is not really
normative.
SteveZ: Seems to me we have 3 possibilities:
SteveZ: (1) John's "must not."
SteveZ: (2) undefined.
SteveZ: (3) should use the font, but failing that can do fallback per
UTR50.
SteveZ: I think those are only 3 on the floor. Appears to me at this
point that the easiest to eliminate is (1).
SteveZ: That leaves us with 2 different ways of saying can fallback,
either by not saying anything or by saying you can.
SteveZ: I'd propose a straw poll that would eliminate the first
option,
SteveZ: And then we can see if there's a significant difference
between other two.
SteveZ: Seems easier to eliminate (1) from straw poll.
fantasai: There's 2 wordings on floor:
<fantasai> "If the vert alt glyph is not present in the font, UA may
but is not expected to substitute the glyph"
<fantasai> vs
<fantasai> "If the vert alt glyph is not present in the font, behavior
is undefined"
<fantasai> ??
SteveZ: I think fantasai's second option captures what we should get
at.
fantasai: The first one is my proposal, because I don't like leaving
things blanket undefined.
r12a: What happened about the straw poll to eliminate (1)?
r12a: Can we resolve to eliminate option 1?
STRAW POLL:
A) "If the vert alt glyph is not present in the font, UA may but is
not expected to substitute the glyph"
B) "If the vert alt glyph is not present in the font, behavior is
undefined"
fantasai: I don't like (B) because it allows the UA to do absolutely
anything it wants.
STRAW POLL:
A) "If the vert alt glyph is not present in the font, UA may, but is
not expected to, substitute the glyph"
B) "If the vert alt glyph is not present in the font, behavior is
undefined"
astearns: A
rhauck: A
dirk: Abstain
Bert: Of these two, prefer A,
zcorpan: Abstain
kazutaka: A
yamamoto: A
Koji: A
Rossen: A
Israel: A
jet: A
chrisL: A
Lea: A
Sylvain: A
3 A's
Dean: Abstain
fantasai: A
dbaron: A
hober: mu
SteveZ: A
Kennyluck: A
Leif: Abstain
Peter: A
TabAtkins: abstain
Bert: My question is, are we really doing what Unicode want us to do?
Bert: Was it really a neutral choice to be doing it or not, or do we
???
fantasai: Descriptions in unicode spec are informative saying what
categories mean, not dictating a behavior.
Bert: If they didn't want implementations to rotate, why did we write
it there?
Bert: I think we're saying opposite of UTR50.
Plinss: UTR50 says can, we're saying may but not expected to.
r12a: Is substitute the right word, or is rotate?
fantasai: Synthesize the substitute glyph
fantasai: wording's a little bit off
Peter: I think "MAY WISH TO" from RFC6919
Peter: I think we should use "MAY WISH TO" and reference RFC6919.
RESOLVED: Accepting option A, with term "MAY WISH TO" and
referencing RFC6919.
<ChrisL> http://tools.ietf.org/html/rfc6919
* sgalineau can't wait for the RFC6919 reference in the new charter
<SimonSapin> "This phrase is frequently used to avoid further delay in
approval of a document."
Peter: Is the spec ready to advance?
fantasai: I expect this to be the first of at least two last calls.
<SimonSapin> seems appropriate
Peter: Anything to rename?
RESOLVED: Take CSS Writing Modes to Last Call.
Peter: break until 11am.
<fantasai> I think there's an open issue on possibly renaming
text-combine-horizontal to something better/easier-to-type
/less-confusing
[Break]
Received on Thursday, 21 November 2013 23:30:14 UTC