- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 11 Mar 2015 20:33:12 -0400
- To: www-style@w3.org
Writing Modes
-------------
- RESOLVED: Keep sideways-left, mark as at-risk, possibly punt if
it threatens CR-exit.
- GregWhitworth will look at what options are valid for where
writing-modes should propagate from - if it can be from <body>
or if it has to come from root or if there are other
approaches entirely.
- RESOLVED: writing-mode: vertical-lr on the <rt> based on
parent's 'display' & 'ruby-position'
- RESOLVED: Drop the values if the SVGWG drops the
values/properties, otherwise keep them.
Multi-line/Block-Ellipsis
-------------------------
- RESOLVED: Replace region-fragment with 'fragmentation', written
by Florian, determine where it belongs.
- RESOLVED: Split fragmentation values of 'overflow' into a
separate property. Further develop this in the
overflow module.
- RESOLVED: region-break gets folded into the new property, too.
- RESOLVED: Florian added as editor to Overflow.
===== FULL MINUTES BELOW ======
Writing Modes
=============
Scribe: TabAtkins
sideways-left value
-------------------
fantasai: Writing modes!
fantasai: We don't have impls of the sideways-left value. Options:
fantasai: 1) Leave it as is.
fantasai: 2) Mark it as at-risk, and note that if someone
implements just sideways-right, don't implement sideways.
fantasai: 3) Punt it to level 4.
fantasai: I think we should do #2 because it's important for
non-CJK upright scripts.
fantasai: Like a caption on the left side of a table, or table
column headers that are vertical in English, you need
this value.
fantasai: So I don't think we should remove it.
fantasai: But if it's the only thing blocking writing modes from
exiting CR, it might be worth dropping it.
TabAtkins: I say keep it in until CR-exit is imminent.
koji: I say move it to Level 4.
koji: Concerns about how it is designed today were raised, and I'd
like further discussion.
koji: So punting is appropriate.
fantasai: Nobody has raised an issue with the design afaik.
fantasai: People have said "I don't like this, it's confusing and
complicated".
koji: Rossen suggested rotating the line 180deg inline.
fantasai: We could make it apply to blocks only if that's the
issue.
plinss: I don't see the harm in marking it at-risk versus punting
it for now.
plinss: Has anyone implemented sideways-right but not
sideways-left?
<koji> AH, Blink, and WebKit does.
fantasai: Yeah, because sideways-right is needed for CJK.
astearns: At-risk seems the right thing to do for now.
Rossen: We can always push it to 4 later.
plinss: Any objections?
RESOLVED: Keep sideways-left, mark as at-risk, possibly punt if it
threatens CR-exit.
fantasai: Next is propagation of writing-mode and direction from
<body>
koji: Did we decide on 'sideways'?
fantasai: Same deal - if you can't do sideways-left, you can't do
sideways.
koji: Okay.
Propagation of writing-mode and direction from <body>
-----------------------------------------------------
fantasai: Right now in HTML we propagate from root to the ICB, and
the proposal is to ignore the value on the root and
propagate from the body to both the root and the ICB.
Ignore the root's value entirely.
Rossen: So if you have <html dir=rtl><body dir=ltr>, it's ltr?
Rossen: Is that a good idea?
fantasai: We need to do something like this. For background, we
can do the "check to see if root has it specified, if
not, check body".
fantasai: But this is inherited - there is always a valid value.
So you have to choose one or the other unconditionally.
Florian: I believe direction is a web-compat issue; it's been that
way forever. We'd prefer it inherit normally, but we
probably can't change it.
Florian: And writing-mode should act similarly.
Rossen: We have logic that doesn't match that since IE6.
Rossen: We take root if specified, and use body otherwise.
Rossen: Same for overflow.
Rossen: This suggestion may have compat issues in cases where both
html and body specify a direction.
Rossen: Before we decide how to spec this, we need to understand
how we're all doing.
Rossen: I hope this is something we can keep consistent for
overflow too.
<fantasai> testcase: data:text/html;charset=utf-8,<!DOCTYPE html>
%0D%0A<title>..]<%2Ftitle>%0D%0A<style>%0D%0A%0D%0A
head%2C title { display%3A block%3B }%0D%0A body
{ border%3A solid%3B width%3A 150%25%3B text-align%3A
center%3B }%0D%0A<%2Fstyle>%0D%0A<body dir%3Drtl>
%0D%0A..]
zcorpan: In Blink it used to use the root element if it was
specified on both, but it was changed to always use
<body>, claiming compat with Gecko and IE.
fantasai: Gecko seems confusing...
dbaron: Gecko is inconsistent based on what is happening.
dbaron: You can test how direction behaves on root by...
dbaron: 1) Which side you can scroll to when there's overflow from
the viewport.
dbaron: 2) If the root element is relpos and has both left and
right set, which one wins.
dbaron: 3) If the root element has overconstrained margins, which
gets ignored.
dbaron: 4) If the root or body is abspos, which position gets used
for hypothetical box calcs.
dbaron: Probably most likely to cause breakage in scroll direction.
<fantasai> dbaron: data:text/html;charset=utf-8,<!DOCTYPE html>
%0D%0A<title>..*<%2Ftitle>%0D%0A<style>%0D%0A%0D%0A
head%2C title { display%3A block%3B }%0D%0A html
{ border%3A solid silver%3B width%3A 80%25%3B margin%3A
0%3B }%0D%0A body { border%3A solid%3B width%3A
150%25%3B text-align%3A center%3B }%0D%0A<%2Fstyle>
%0D%0A<body dir%3Drtl>%0D%0A..*
[some discussion about <title> direction]
<fantasai> Presto scrolls as LTR (follows root).
<fantasai> Gecko aligns as LTR, but scrolls as RTL.
<fantasai> which is not helpful at all.
<fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Ctitle%3E..*%3C%2Ftitle%3E%0A%3Cstyle%3E%0A%0A%20%20head%2C%20title%20{%20display%3A%20block%3B%20}%0A%20%20html%20{%20border%3A%20solid%20silver%3B%20width%3A%2080%25%3B%20margin%3A%200%3B%20}%0A%20%20body%20{%20border%3A%20solid%3B%20width%3A%20150%25%3B%20text-align%3A%20center%3B%20}%0A%3C%2Fstyle%3E%0A%3Cbody%20dir%3Drtl%3E%0A..*
<zcorpan> <title> seems like UI QoI.
<fantasai> Blink aligns and scrolls as RTL.
<fantasai> IE shows the whole canvas and can scroll to it, and
aligns per RTL, but the initial scroll position is per
LTR.
Florian: So more testing to see what exactly is happening, and
which is interoperable?
fantasai: Whichever one is less likely to cause breakage is what
we should do.
dbaron: Fixing the spec might make things inconsistent too.
dbaron: You'll need to make up some new term, not computed value,
and you'll need to make sure everything refers to this new
term, not "computed value".
<fantasai> https://lists.w3.org/Archives/Public/www-style/2015Jan/0272.html
<fantasai> 710 pages with <body dir=rtl> and not <html dir=rtl>.
(0.24%)
<dbaron> https://bugzilla.mozilla.org/show_bug.cgi?id=1071098#c16
is where I got the list of ways to test direction on the
root
<dbaron> fantasai: could propagate from the HTML attribute on the
body, but not propagate CSS 'direction'
<TabAtkins> html:has-child(body[dir=rtl]) { direction: rtl; }
<TabAtkins> DONE
ACTION GregWhitworth to figure out what options are sensible for
the html/body dir thing.
<trackbot> Created ACTION-672
<br dur=15m>
Loop from Ruby and Writing Modes
--------------------------------
dbaron: Xidorn tried to implement something, and we found a
problem.
dbaron: In CSS sometimes the process of computing one property
depends on another one.
dbaron: And we need to keep these in a partial order, so no loops.
dbaron: We discovered that Ruby and Writing Modes added a loop.
dbaron: It's between 'display' and 'writing-mode'.
dbaron: There's also an influence from 'ruby-position'.
dbaron: display:ruby-text-container && ruby-position:inter-character
=> writing-mode computes to vertical-rl
dbaron: Because intercharacter ruby needs to be drawn that way.
dbaron: I've seen elevator signs in Taipei look like this.
dbaron: When writing-mode changes between parent and child, and
display is inline, it's changed to inline-block.
dbaron: Because you can't really display a writing mode change
unless the parent establishes a block.
dbaron: I think most of us agree that writing-mode has to mess
with display.
dbaron: So it's not strictly a loop, but this still doesn't work
in our architecture.
dbaron: roc suggested that the vertical-lr change be triggered by
something else that display:ruby-text-container elements
have.
TabAtkins: So our problem here is that we have a strict separation
of properties into "levels" that compute in order.
dbaron: Ours isn't strict, but we do have a strict ordering of
inherited vs non-inherited properties, which ends up being
the same thing.
fantasai: We could make the inline->inline-block a used value.
dbaron: Making the computed value out of sync with the real value
will be a security issue.
[missing some minuting]
TabAtkins: I think roc's suggestion can work. Add a magic property
to <rtc> and anonymous ruby text containers. Authors
have to add it manually if they're making their own.
fantasai: Can this just be an implementation issue? That's a weird
contorsion for authors.
[dbaron's thinks furiously]
dbaron: What does it look like in inter-character ruby when there
is an <rtc> with multiple <rt>s?
fantasai: Each rt is after each rb. The rtc and rbc both encircle
the entire thing.
dbaron: That makes it sound like it's the rt that's vertical-rl,
not the rtc.
dbaron: If so, can we fix by changing the condition to "my
parent's display is rtc and my ruby-position is inter-
character"?
fantasai: Or parent's ruby-position is inter-character.
dbaron: If it's the ruby-text that becomes vertical-lr, I think
that's okay.
fantasai: Sounds good.
RESOLVED: writing-mode: vertical-lr on the <rt> based on parent's
'display' & 'ruby-position'
all shorthand question
----------------------
heycam: The 'all' shorthand is designed to exclude direction and
unicode-bidi.
heycam: Why?
fantasai: Direction and unicode-bidi should never have existed.
They're not stylistic, they're content properties.
fantasai: So when resetting stylistic stuff, they shouldn't be
reset.
fantasai: But writing-mode *is* a stylistic choice.
heycam: And text-orientation too?
fantasai: Yes.
SVG Keywords - kill them?
-------------------------
heycam: There are some SVG-specific keywords in writing modes.
heycam: text-orientation:use-glyph-orientation, which means "do
what the SVG-specific glyph-orientation-
vertical/horizontal properties say".
heycam: I was going to suggest to SVGWG to just drop those, since
nobody implements them.
heycam: Presumably you'd drop the value if we drop the properties.
fantasai: Yes.
heycam: Next is some writing-mode values, coming from XSL.
heycam: We're going to drop all of those, and just refer to
current CSS spec.
heycam: So I suggest they get dropped from CSS.
fantasai: Can you actually drop them?
fantasai: It's reasonably likely there's no web content that uses
them, but may be off-web content that uses them.
TabAtkins: Can we just death-pact with the SVGWG and choose to
drop them if they do?
heycam: At least we'll drop them from SVG2.
fantasai: But you'll still need the definition.
fantasai: We might deprecate and define them simultaneously.
heycam: In WM atm, there's wording that says "if you support these
values, do XXX".
heycam: We'll let you know what we decide.
heycam: I found an old email of mine saying that some browsers do
implement glyph-orientation-*, but they didn't do it
interoperably.
fantasai: If the values only show up in attributes, you can use UA
CSS to convert it to the proper values.
fantasai: But if the existing content uses the CSS syntax, you
need to keep it.
RESOLVED: Drop the values if the SVGWG drops the values/
properties, otherwise keep them.
<krit> This is exported from Photoshop:
<krit> .cls-15 {
<krit> writing-mode: tb;
<krit> glyph-orientation-vertical: 0;
<krit> }
<heycam> krit, ok, that is interesting
Multi-line/block ellipsis
=========================
<dbaron> https://lists.w3.org/Archives/Public/www-style/2015Jan/0357.html
Florian: Not the first time we've discussed this.
Florian: To refresh everyone, we have ellipsis.
Florian: It only works in in the inline dimension. If a given line
is overflowing, it gets ellipsized.
Florian: Most people want something at the end of the last line of
a block that's too long in the block direction.
Florian: We actually have a resolution to add it to the spec,
without specifying what's getting added.
Florian: So I was looking into this...
Florian: I have some ideas, but while working on this, I figured
this was a problem that should be unified with something
similar, and so I'll be talking more about fragmentation
than ellipsis.
Florian: When you say "I want ellipsis at the end of the last
line", what does that mean? Last totally-fitting line?
Does ink(shadow) count?
Florian: Or do we just use fragmentation, which defines all of
this?
Florian: There's a property in the Regions spec called
region-fragment.
<astearns> http://dev.w3.org/csswg/css-regions/#the-region-fragment-property
Florian: It has 'auto' or 'break'. If the last region of the
region chain overflows, and it says "auto", it overflows
like normal. If 'break', it acts like there's another
region, but just drops the rest.
fantasai: This sounds like another value for overflow-y.
<fantasai> This is overflow-y: paged-hidden
Florian: The Regions spec shows why that's not true; it's
independent of overflow.
astearns: overflow-x/y can have effects independently of
region-fragment
TabAtkins: Regardless, I think you're not invoking the property
itself, just its concept?
Florian: I think we can generalize this concept.
Florian: [described the definition of the property again]
fantasai: So you have overflow:scroll and hidden.
fantasai: Same, but hidden just stops it rather than exposing the
rest.
fantasai: Similarly, this is like paged and "paged-hidden" - "page
me, but don't expose the rest".
dbaron: I agree with Florian.
dbaron: When I was writing the Overflow spec, I found this awkward.
dbaron: It was trying to put two different concepts in the
Overflow property, one about visual overflow and one about
pagination.
dbaron: It was awkward that there were 'overflow' values (page and
fragments) that were about how to paginate, so when you
had those values, you had to arbitrarily pick what to do
with the visual overflow that visible/hidden handled
normally.
fantasai: So that makes sense to me; maybe different properties
for visual vs pagination overflow.
fantasai: I'm okay with that.
fantasai: As long as pagination and hiding pagination are in the
same control.
Florian: That's chapter 5 of my very long mail.
Florian: So my new proposal is a 'fragmentation' property.
Florian: With values auto/none/break/paged/clone
Florian: Auto is "do the right thing in the middle of a region
chain", etc
<fantasai> break is region-break: break behavior
<fantasai> paged is overflow: paged
<fantasai> clone is overflow: fragment
Florian: Should we explain regular pagination in terms of this?
Florian: By having this property on the page box, having "auto"
compute to "paged", which lets you turn off pagination on
a page and let things overflow.
Florian: Dunno if that's useful.
Florian: Reason this ties into ellipsis is that we have an issue
about block ellipsis, and another issue about "how can we
write 'continue on page 3'", we can unify these.
Florian: So we'd solve the "put ... at the end of a block" the
same way as "put ... at the end of a region that
continues elsewhere", and eventually "put (page 3) at the
end of a region" when we have those tools.
tantek: When I've seen "include the first 3 lines" behavior, it's
usually on social networks with a "more" link.
tantek: I don't know how to combine auto-ellipsizing that and
adding a link that you can attach some other behavior to.
Rossen: We discussed this in Seoul.
Rossen: Talked about what to do with ellipsed behavior.
Rossen: We added the "fade" ellipsis behavior, and there was talk
about styling it, so it should be a pseudo-element.
Rossen: So the ellipsed block is actually interactive. You can
attach event handlers to the pseudo-element.
Florian: Another possibility is adding a "fragment: into(<sel>)"
that we could use later.
fantasai: Bert had a pull model that I think makes more sense than
into(<sel>).
tantek: I think I'm okay with unifying.
tantek: So we need a string, not just "ellipsis".
TabAtkins: You can attach an event listener to the parent of the
::ellipsis pseudo, and do the "more" handling there.
tantek: So one behavior is an expansion when you click "more".
tantek: Another is "more" being a link to another page.
tantek: Third is "continued on page 3", where it loads totally
different content, maybe saying "continued from page 1".
tantek: Another scrolls down to another part of the page.
tantek: I'd like to at least capture those.
<dbaron> And some websites use both, and you can't tell which
you're going to get until after you click it.
TabAtkins: First two can be done with JS now; doing it CSS
requires reviving the Hyperlink module. Third can be
done as Region expansions in the future.
Florian: My basic point is that if we try to solve block ellipsis
separately from fragmentation, we'll have to solve these
problems twice.
johanneswilm: As I understand it, if you can have an ::after
pseudo element that you put the ellipsis in, you can
use JS to figure out what page something shows up
on, and set 'content' appropriately.
tantek: It's definitely solvable in JS today. Just want to let
there be less JS, or no JS.
Rossen: If your container is actually constrained so there's only
two lines visually, you say max-lines:3, the behavior is
still bad.
Florian: No, max-lines:3 just puts a break opportunity after the
3rd line.
Florian: Currently max-lines only applies to overflow:fragments;
it should apply to any fragmentainer.
TabAtkins: Yes, assuming we have these new fragment values.
Florian: So, proposal is we remove region-fragment property,
replace it with the 'fragmentation' property.
dbaron: I'm okay for now, haven't looked into the details.
tantek: I agree with the general scope of the proposal.
RESOLVED: Replace region-fragment with 'fragmentation', written by
Florian, determine where it belongs.
fantasai: Why is max-lines only usable on fragmentainers? Should
be on all block containers.
[discussion over this]
[???]
[unminuted discussion about fragmentainers]
[height, fragment or not, making breaks]
Florian: So right now, if you say max-lines:3 on a <p> in the
middle of a page, it'll break the page after the third
line.
Florian: Which is silly, so we need the <p> to be a fragmentainer.
Florian: To be automatic, maybe max-lines:non-none causes
fragmentation:auto to compute to 'break'.
fantasai: 'break' is a non-obvious name.
TabAtkins: Maybe 'discard'.
Rossen: So max-lines is non-inherited.
fantasai: So, what I understand is that the proposal is to take
the values of 'overflow' that deal with fragmentation
and make them into a separate property, and add a value
that does fragmentation but hides the overflow instead
of continuing it on another page/clone.
Rossen: So what if you have <div style="max-lines:3;"><div>...
</div></div>
Florian: Well, regardless of that answer, max-lines should apply
to any block.
astearns: dbaron defined this well in the Overflow spec where he
tries to take your case into account.
astearns: We can resolve the issue over there.
<astearns> http://dev.w3.org/csswg/css-overflow/#max-lines
astearns: But the discussion is about fragmentation.
Florian: So do we want to do regular pagination with this
fragmentation property?
fantasai: I was thinking paging was overflow:paged on the root
element.
fantasai: overflow:paged creates pages the same way that scrollbox
creates a scrollable canvas in the viewport. Instead of
scrolls, you get pages.
fantasai: Each of those pages are style-able with an @page rule,
regardless of whether the whole doc is paged, or a small
section.
Florian: So in some contexts, auto becomes paged, and maybe
'break' becomes 'overflow:hidden' or whatever on the root
element.
RESOLVED: Split fragmentation values of 'overflow' into a separate
property. Further develop this in the overflow module.
<johanneswilm> Has it been defined what kinds of elements each of
those pages has?
<johanneswilm> (header, body element, footnote area, page number
area, page float area?)
<johanneswilm> Or can it be definable by the user?
Florian: That property that gets separated out is the
region-fragment property. So pull it out.
RESOLVED: region-break gets folded into the new property, too.
astearns: If this goes into Overflow, add Florian as an editor?
dbaron: Yes.
RESOLVED: Florian added as editor to Overflow.
fantasai: Do we have a def of overflow-x/y?
dbaron: Kinda, in Overflow.
fantasai: I was gonna say that when we have that, we cut that as
Overflow 3 and have everything new in Overflow 4.
Florian: I think region is the only fragmentainer that has
::before/after, but now you can.
astearns: We needed ::before/after in our processing model to see
how they work in named flows.
astearns: If we assume that ::before/after are always blocks in a
fragmentainer (what we currently do), then we'd want to
extend that.
fantasai: What if the remaining space is negative?
Rossen: Defined in the region spec.
fantasai: Can they turn into run-ins?
Florian: I'd like to.
Florian: When you're doing ::after on fragmentainer, there are
cases you want to only do ::after if you're fragmenting.
Florian: So maybe have an ::ellipsis-like thing to help handle
that.
fantasai: Then we have the remaining issue about how to make it
interactive.
florian: That's a general pseudo-element issue.
fantasai: Yes, but it's a core part of these use cases; not so
much for other pseudos.
heycam: How do you align the ::ellipsis? For the block one, does
it appear as a block right below?
Florian: The way I remember it is "you know how wide this thing
is, so you can lay out your ::after".
johanneswilm: I tried to do footnotes with regions, and
::before/after were problematic.
johanneswilm: I couldn't have a footnote marker get left behind,
etc.
[johanneswilm and dauwhe got distracted by footnotes and went
off-topic]
dbaron: I initially wanted [it] that way...
dbaron: We realized there was a problem that you design some style
with overflow:fragments, style each fragment,
dbaron: Then 'fragment 2' gets a page break in it.
dbaron: You don't want your styles to be one off because your
'fragment 3' styles get applied to the second half of what
was originally 'fragment 2'.
dbaron: Probably a way around that, but we're getting complicated.
<br dur="til morning">
Received on Thursday, 12 March 2015 00:33:41 UTC