- From: Dael Jackson <daelcss@gmail.com>
- Date: Fri, 29 May 2015 21:22:30 -0400
- To: www-style@w3.org
Writing Modes
-------------
- RESOLVED: No spec change for writing-mode on table cells
- RESOLVED: No propagation of 'direction' from body to html,
propagate dir attr with `html:not([dir]):has(>body:dir(
rtl)) { direction: rtl; }, back out if web compat
problems
- RESOLVED: writing-mode and direction need to have the same
propagation behavior, so writing-mode compat affects
the previous resolution (which may be rescinded)
- gregwhitworth and smfr will investigate web compat of not
propagating writing-mode from body to html to try and come to
a resolution on the discrepancy between the previous two
resolutions.
- RESOLVED: Writing Modes spec adds an example of blocking
inheritance into SVG; blocking is not automatic
- RESOLVED: Clarify the spec to correctly explain how to implement
sideways and how to not implement sideways-left
- RESOLVED: Don't mark vertical-lr at risk
- Auto-sizing block containers in orthogonal flows will be marked
at-risk
===== FULL MINUTES BELOW =======
Present:
Rossen Atanassov
Tab Atkins
David Baron
Bert Bos
Bo Campbell
Tantek Çelik
John Daggett (phone)
Elika Etemad
Daniel Glazman
Koji Ishii (phone)
Ian Kilpatrick
Chris Lilley
Peter Linss
Simon Fraser
Florian Rivoal
Andrey Rybka
Simon Sapin
Doug Schepers
Shane Stephens
Lea Verou
Jet Villegas
Johannes Wilm
Greg Whitworth
Steve Zilles
Regrets:
John Daggett
Dael Jackson
Simon Pieters
Anton Prowse
Hyojin Song
Alan Stearns
Agenda: https://wiki.csswg.org/planning/new-york-2015#agenda
Scribe: SimonSapin
Writing Modes
=============
Deferring Orthogonal Table Cells
--------------------------------
<presenter> https://lists.w3.org/Archives/Public/www-style/2015Apr/0387.html
koji: First issue is proposal to defer orthogonal table cells
fantasai: The idea is we don’t have interoperable implementations
for writing modes applied to a table cell (you can apply
to contents of a table cell).
fantasai: The proposal is to defer to level 3.
fantasai: I don’t think this makes sense, but problem is that we
don’t have implementations e.g. for vertical table
headers, so Koji suggests to defer.
Rossen: Did you test IE?
fantasai: Yes, we found bugs.
fantasai: I don't think it makes sense to defer to next level.
jet: Single cells?
fantasai: Yes.
fantasai: My position is we should keep it.
Rossen: I agree.
fantasai: Deferring means if you apply a writing mode to a table
cell, some impls will apply, some will ignore.
glazou: What does it mean in terms of spec? Behavior undefined?
fantasai: We can do 3 things:
1) leave the spec alone
2) say it’s undefined
3) say that for applying WM to a table cell, either you
do X or pretend it doesn’t apply.
dbaron: Writing modes inherits, right?
fantasai: Yes.
fantasai: We need to look at why it’s not implemented.
<gregwhitworth> This works in IE/MS Edge: http://jsbin.com/videdumeme/2/edit
SteveZ: Ignore the property?
fantasai: That’s option 3
fantasai: Undefined means weird things can happen.
dbaron: It’s kinda weird to ignore an inherited property on just
some elements.
dbaron: On inner table elements like rows is use the WM of the
table.
koji: You already apply WM to the table’s contents.
<koji> Spec currently says "All elements except table row groups,
table column groups, table rows, and table columns"
dbaron: Ignoring it means you do the same for a cell, which acts
like it has the WM of the table,
dbaron: but the anonymous block inside the cell uses the WM of the
cell.
fantasai: If it's done correctly, that’s same results.
dbaron: Except for logical properties.
fantasai: True, but we don’t have those yet, so from the POV of the
spec it doesn’t make a difference.
dbaron: I don’t see how it would be extra work to make it apply at
least on the anonymous block inside the table cell.
koji: Some differences in table cells when applying borders.
<koji> I think table cell has some differences in borders,
colspan, etc.
<koji> IE fails most of these tests as of today
<fantasai> colspan!?
<koji> Since WebKit and Blink does not apply to td/th
<koji> Authors already work around by putting a div/span inside
table cells
dbaron: colsan and rowspan are still relative to the table’s WM I
hope?
TabAtkins: Yes.
TabAtkins: A colspan spans columns.
dbaron: Who is pushing to change the spec?
TabAtkins: Koji is
<koji> me
fantasai: My preferred solution would be file bugs against impls.
gregwhitworth: Rossen: Agree.
fantasai: Anyone have a different opinion?
Chris: So your opinion is that the spec is clear?
fantasai: On that topic, yes.
glazou: What does this mean to go to REC?
fantasai: Bugs need to be fixed before REC.
glazou: Are browsers interested in fixing this?
jet: We’re implementing now.
glazou: Should it be at-risk?
Chris: There is no downside to marking at-risk.
Florian: You also can mark at-risk + say "we can drop from must to
should".
SteveZ: In that case, fantasai wants a fallback which in my mind
means to ignore the property.
fantasai: So `td, th { writing-mode: inherit !important}` in the
UA stylesheet?
fantasai: Effectively.
Chirs: With a comment: do it properly or not at all.
<koji> If not supported, it should be the same as when applied to
<tr>, no?
jet: Sounds like implementers want to leave it in
fantasai: You (IE) want the spec to stay and you’ll fix your bugs?
Rossen: Can you be more specific?
fantasai: So if we write test cases where you fail, you’ll fix it?
Rossen: That’s how it works.
fantasai: I think it should stay, but it’s up to the WG.
glazou: Let's do a straw poll.
glazou: Two options: should stay in the spec, or not
Florian: and marked at risk
<Florian> Stay in the spec, mark at risk, with clarification that
at risk means may drop from must to should
<fantasai> 1. No change to spec
<fantasai> 2. Say it is undefined
<fantasai> it = what happens when writing-mode is applied to a
table cell
<fantasai> 3. Mark as at-risk and specify what happens if it's not
implemented
1: 8 hands raised
2: none
3: 6 hands
* fantasai notes that Microsoft, Blink, and Mozilla reps were all
for 1
Florian: What’s the downside of 3? It's the same as 1 plus
insurance.
dbaron: Plus extra work.
fantasai: You need to specify both "should" and the alternative.
<koji> I can try to define the alternative
glazou: 1 wins. Anyone objects?
<koji> ok
RESOLVED: No spec change for writing-mode on table cells
Propagation of the direction property from <body>
-------------------------------------------------
fantasai: We're not really getting information on why would
anybody would do that.
gregwhitworth: It's faster to make the switch and see how much
stuff breaks.
fantasai: Proposal: propagate the dir attr value from body to html,
fantasai: rather than the direction property.
<koji> does the proposal include writing-mode?
fantasai: The advantage is that the direction property has lots of
side-effects on the root: scrolling direction, scrolling
origin, alignment of things in the root, cascading…
fantasai: It's lots easier and less buggy if none of these things
had to be special-cased for body.
fantasai: You only pay attention to direction on the root.
fantasai: It's less buggy impls, the main question is can we pull
that off in web content.
fantasai: There's some data, but it's hard to tell what’s going on.
fantasai: One survey says the direction property is used in like
88% of web pages, which is ridiculous.
fantasai: Maybe it’s in some library.
fantasai: One of the browsers should release a nightly build and
see if that works.
fantasai: Lots of simplification in layout engines, consistency,
less bugs.
fantasai: I'm worried about e.g. logical properties.
dbaron: The proposal is that dir attr on body sets the direction
property on html?
fantasai: Yes.
fantasai: It’s only one line with a child selector.
SimonSapin: You mean :has()?
fantasai: Yeah.
dbaron: You also have to handle dir=auto.
dbaron: Is there a difference with dir=auto on html vs body?
fantasai: Yes: on html, also looks at the title.
dbaron: And maybe style and script elements?
fantasai: Yeah, probably you don’t want to set dir=auto on the
html element.
dbaron: I don’t know about interop. Gecko’s behavior is a bit
random, 5 things that should be propagated but only some
do. No good sense of compat risk or how reliable other
impls are.
fantasai: Testing showed lots of bugs.
fantasai: Do we want someone implementing this, or more data, or
not do this?
SimonSapin: I'm in favor of the proposal.
Bert: I would like to get rid of propagation from body as much as
possible, e.g. background was an anomaly.
fantasai: Probably this is the best we can do.
fantasai: 2 variations up to HTML WG: 1. propagate the resolved
direction (accounts for auto on body, not particularly
necessary) 2. just propagate dir=rtl
<fantasai> html:has(>body[dir=rtl]) { direction: rtl }
<fantasai> html:has(>body:dir(rtl)) { direction: rtl; }
<fantasai> (insert a :not([dir]) after the html there)
<fantasai> I don't think it matters which one we take, both are
fine for web-compat, and using dir=auto on <body> is
stupid
dbaron: Don’t think the current HTML WG is suited to make this
decision.
fantasai: I mean the people who work on these things.
dbaron: That’s us.
dbaron: Probably more sensible to handle dir=auto on body.
dbaron: Makes more sense than on html.
fantasai: other opinions?
<koji> writing-mode?
<fantasai> koji, I think we have to handle that as a separate issue
<koji> ok, good then
fantasai: Works for me.
glazou: We need to resolve or move on. Good to go?
TabAtkins: Yeah.
gregwhitworth: Good to go but we need other impls to follow.
dbaron: Someone just wrote a patch, waiting for review. Don’t know
if it does what this says.
gregwhitworth: Can we resolve on doing this unless web compat is
terrible?
fantasai: Yes.
fantasai: Proposed resolution: no propagation of 'direction' from
body to html, propagate dir attr with that rule above,
back out if web compat problems.
fantasai: Sounds good?
glazou: No objection?
<koji> yes, good
RESOLVED: No propagation of 'direction' from body to html,
propagate dir attr with `html:not([dir]):has(>body:dir(
rtl)) { direction: rtl; }, back out if web compat
problems.
Propagation of writing-mode
---------------------------
<koji> can we also resolve for writing-mode?
<koji> ...or at least discus?
dbaron: If this works, it makes sense not to propagate
writing-mode,
dbaron: if not, keep them together,
fantasai: Seems ok.
<koji> But propagating dir attribute implies propagating direction
property, no?
<fantasai> No, it's different.
<koji> I prefer propagating writing-mode,
<koji> as that's what IE/WebKit/Blink does today AFAIU.
<koji> If those two are linked, I'm not ok with the proposal for
dir.
dbaron: If we want WM to propagate at the CSS level we should undo
that resolution and propagate direction at the CSS level
as well,
dbaron: though maybe in terms of effect, not necessarily in terms
of computed values,
dbaron: ... on the root.
fantasai: We have to figure out what to do for writing-mode. If it
has to propagate, direction does too.
fantasai: IE WebKit Blink all propagate.
fantasai: The issue would be, can we turn it off?
<koji> Quite possible to break lots of EPUB
Rossen: In our case, vertical/rtl doesn’t make a difference.
Rossen: I’m gonna be opposed to different handling.
fantasai: Agreed.
fantasai: You currently propagate writing-mode from body to html,
would you be able to turn that off?
Rossen: We can, if everybody else does it at the same time.
fantasai: Other impls are WebKit and Blink.
TabAtkins: I have no idea.
gregwhitworth: Maybe a good starting point is understand the
compat issue.
fantasai: It is more […], we have more options to solve with
direction, because of the dir attr, but writing-modes is
only CSS.
fantasai: Sounds like Microsoft is willing if Blink and WebKit
also ship without propagation. What is the state of the
content you need to deal with?
fantasai: Concern that there are pages out there that set writing-
modes on body and expect the whole thing to be vertical
text.
<koji> I don't have data, but estimates it breaks several EPUB
content.
gregwhitworth: Do we wanna unresolve?
fantasai: We can resolve that direction and writing-mode need to
have the same propagation behavior.
gregwhitworth: I can give sites that are using writing-mode on
body, be would be good if webkit/blink can also
investigate.
RESOLVED: writing-mode and direction need to have the same
propagation behavior, so writing-mode compat affects the
previous resolution
fantasai: Action item for that?
gregwhitworth: I’ll take it, but good if everybody else looks
into it.
gregwhitworth: ebooks and stuff.
ACTION gregwhitworth Investigate web compat of not propagating
writing-mode from body to html.
<trackbot> Created ACTION-687
ACTION smfr Investigate web compat of not propagating writing-mode
from body to html
<trackbot> Created ACTION-688
<koji> I'll try to look into too
* fantasai notes that result of ebooks layout might not be
affected if 7.3.2 is implemented fully ^_^
fantasai: 7.3.2 is automatic use of multicol. Since ebooks don’t
scroll, the default column size is the full size of the
viewport. Long horizontal document with vertical
columns … ends up with the same result.
fantasai: Only problem with scrollable web page, scrolling origin
is in the wrong place.
fantasai: If you set w-m on body and it doesn’t propagate, you
only notice it in scrolling.
fantasai: You don’t implement auto multicol, it does make a
difference.
fantasai: If you have one long thing and only print the first
chunk of it,
fantasai: might be that we can not propagate if we handle auto
multicol in orthogonal flows.
SVG
---
fantasai: Issue is that writing-mode property will inherit into
embedded SVG.
fantasai: In some cases you want that, if decorating text,
fantasai: in most cases, that’ll break your coordinate space.
fantasai: Do we block inheritance of writing-mode in SVG?
ChrisL: There are lots of cases when inheritance is unwanted.
ChrisL: MathML doesn’t do vertical text, SVG tries.
fantasai: You render MathML sideways, it ignores writing-mode.
<koji> yeah, but the problem of writing-mode is coordinate system
is always physical
Rossen: If you have foreign objects with HTML inside, you might
want to propagate.
dbaron: It seems like if pasting SVG into HTML, there’s a ton of
things that inherit. Fonts, … If you want your SVG to be
isolated, not be part of the context, you should be using
object or img or iframe.
fantasai: We can block with `all: initial`.
TabAtkins: Except direction, because it shouldn’t have been a CSS
property.
TabAtkins: And unicode-bidi.
fantasai: We want that to happen at the HTML layer.
fantasai: Direction is not the problem here. If you’re pasting
graphics with text, chances are it’s in the same
language.
shepazu: It's confusing either way. Some people will expect either
behavior. As long as there is a way to achieve both. Have
a way to block all these things at the SVG layer.
shepazu: It’s gonna be confusing for somebody no matter which way
we go.
ChrisL: Mention it in the SVG integration spec?
fantasai: The way to do it is to set `all: initial` and maybe
`direction: initial`. Is that the default? Or does the
default inherit through?
fantasai: 2 things is that `all: initial` would block inheritance,
`all: unset` would get it back.
shepazu: Once you see a graphic you don’t expect it to change
based on context. So you want the default to not
propagate.
TabAtkins: You’re dropping literal markup.
shepazu: I still think it’s more intuitive to opt into propagation.
fantasai: You also run into bugs when the author didn’t look at
that particular graphics when translated… or change some
font property.
fantasai: It's more obvious if the text is off.
shepazu: We don’t know how they’re bringing that markup. Are they
using D3?
shepazu: They could do it in a blog. Blocking is more intuitive,
and make it clear how to unblock.
fantasai: Proposed resolution: CSSWG recommends to SVGWG to block
inheritance of CSS properties using `all: initial` at
the SVG/HTML boundary.
dbaron: There's a compat risk; this is used.
glazou: Yes.
Florian: It would be fine 10 years ago, but SVG is used now with
inheritance; we’re changing behavior.
glazou: SVG editor in Bluegriffon. You can select the whole
document and make it bold. It just works.
glazou: This would change behavior in a way that may not be
understandable.
ChrisL: The problem is two situations where people expect opposite
things. Not clear which should be the default.
shepazu: We’re mostly talking about text.
TabAtkins: Color matters. `fill: currentColor`
TabAtkins: It can be done now, we’d be breaking graphics if we
change it to black.
jet: Should the SVG WG be doing this?
fantasai: The spec should explain how to do the other behavior.
Rossen: I’m with dbaron. Web compat is gonna be a challenge. If
you want to do this, it should be opt-in.
Florian: It should be on the svg element.
Rossen: It's too big of a knob.
ChrisL: The all property is already a big knob.
Florian: SVG is just an image, or it’s part of the document.
Having that switch, that can still be overridden.
plinss: The other problem when people want isolation of style. Why
special mechanism just for SVG?
ChrisL: Lea suggested the seamless attribute to do the opposite.
leaverou: That was more a joke.
ChrisL: When you want to inherit into <object>
fantasai: So inherit, and use `all: initial` if your image is
screwed up.
fantasai: We need notes on both specs, especially for
`writing-mode: unset`.
fantasai: SVG spec in embedding should talk about this.
shepazu: Somebody’s gonna be surprised either way.
fantasai: If we have existing content, we can't change default
RESOLVED: Writing Modes spec adds an example of blocking
inheritance into SVG
[SVG spec should also add examples of blocking inheritance with
all: initial ]
<break duration=15m>
Scribe: gregwhitworth
sideways-left
-------------
fantasai: We have three keywords.
fantasai: Depending on the block direction sideways will get you
the direction of the non-cjk language,
fantasai: as though the block was rotated.
fantasai: [shows diagram of sideways props]
https://lists.w3.org/Archives/Public/www-archive/2015May/att-0012/sideways.jpg
fantasai: sideways-right is the same as sideways in vertical-rl
(Chinese, Japanese, etc.), but looks backwards to us
(and correct in Mongolian) in vertical-lr
fantasai: sideways-left is the opposite orientation
fantasai: sideways automatically switches between the two, based
on what's correct for non-vertical writing systems
fantasai: You just want to set writing-mode on the root element
and have it work.
fantasai: The issue we have is implementors have not implemented
sideways-left.
fantasai: Because of this if you set vertical-lr together with
sideways, webkit will give you the sideways-right
behavior.
florian: Isn't the bottom right to embed Arabic in English?
fantasai: Yes, you're right, there are use cases for this.
fantasai: Also there is an obscure script that uses this as well.
fantasai: We have implementors saying sideways-right is good, and
sideways, but not sideways-left.
fantasai: This is not right, this is a conflict, you can't
implement sideways and not implement sideways-left.
florian: Given what you want for Mongolian, do we need sideways?
fantasai: It's trivial to implement once you have sideways-left,
and it helps with side captions being correct
automatically for non-East-Asian writing systems.
florian: Fair enough.
fantasai: Either implement both sideways-left, or drop vertical-lr
support, or update the spec.
fantasai: We could mark vertical-lr at risk.
fantasai: We can change the meaning of sideways.
fantasai: Those are the things that we can do for the spec.
florian: The naming we have now favors English.
florian: Maybe we should focus the short keyword on doing the
right thing for Asian languages since writing-modes is
for fixing these issues.
simon: What is the difficulty with sideways-left? And don't you
have the same issues with sideways-right and RTL?
fantasai: No, the issue is with the coordinate system being
different.
fantasai: All other values, the baseline shift goes towards the
right.
fantasai: In sideways-left, the baseline shift goes towards the
left.
fantasai: And you may have both of them in a line, so you will
have a coordinate system for your linebox that shifts to
the right, and then inside of this you may have to flip
this for a range of text.
dbaron: Gecko implements sideways-right, but not sideways or
sideways-left.
dbaron: Another complication that sideways-left introduces is how
floats will work, technically float: left and float: right
can be swapped within a block formatting context.
dbaron: The spec needs to be switched to floats that are on the
right/left of the bfc, etc.
dbaron: Once you introduce sideways-left you may have a bfc where
they swap.
<dbaron> (that's issue 5 in the spec)
Bert: Why is this different than Japanese?
fantasai: Because it works differently and the float will go where
it should go like normal, just in vertical.
florian: That way float: left would be float: top?
ratan: That is how our implementation currently works, it's
generic to the bfc
<dbaron> http://dev.w3.org/csswg/css-writing-modes/#logical-to-physical
is a useful table
fantasai: We have this issue where Webkit is not per spec.
fantasai: I believe this is the same for Blink as well.
fantasai: There's three options:
fantasai: 1) Change meaning of sideways to sideways-right
fantasai: 2) Webkit/Blink drops support for sideways keyword
fantasai: 3) Webkit/Blink drops support for vertical-lr
fantasai: 4) Webkit/Blink implements sideways correctly
florian: Do we actually have a choice or are there compat concerns?
fantasai: Not really, there won't be a lot of compat risk.
fantasai: The case when you would hit this, is foreign text in a
Mongolian document where you used 'sideways' to render it.
That's the only case where this would break compat.
fantasai: I want to know what Webkit/Blink think about the options
tabatkins: ¯\_(ツ)_/¯
<koji> As a personal I prefer 1.
florian: Number 1 makes the most sense to me.
Bert: Are these values to be used in CJK texts?
fantasai: Yes.
fantasai: Say you're embedding a word "O'Connor" in CJK text.
fantaai: In mixed mode it would look wrong because the letters
would be sideways, but the apostrophe would be upright.
fantasai: You would set [lang-en] {sidways-x} for the name so that
it display correctly as a sideways run.
florian: For CJK sideways and sideways-right are actually the same.
smfr: I'm looking at some webkit test cases and sideways and
sideways-right differ in glyphs used.
fantasai: Well then that's wrong, the spec is clear that sideways
equates to sideways-right.
florian: So your sideways, is a kind of mixed not a kind of
sideways, so drop it?
smfr: But we did this for Japanese books.
fantasai: From the testing it looks like we landed on two...
tantek: Has webkit ever dropped the support for a keyword?
tantek: I don't think that we should resolve on it if it's never
happened.
<fantasai> koji, do you have a testcase for webkit 'sideways'?
<koji> It used to work as an alias to sideways-right AFAIK
<fantasai> It doesn't seem to atm
<fantasai> smfr's testcase works same as mixed
<fantasai> koji, webkit also says they can change names when
dropping prefix
<fantasai> koji, So, is there still an issue?
<koji> I'm not really following...so which option WG prefers?
<fantasai> koji, WG testing shows 'text-orientation: sideways' is
not supported by WebKit
<fantasai> So, it seems option 2 is ok.
<koji> It used to, at least for a few years, and Bilnk does today
fantasai: I need a testcase
<Bert> Neither writing-mode nor text-orientation is in Safari's
documentation.
<fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22-webkit-writing-mode%3A%20vertical-lr%3B%20-webkit-text-orientation%3A%20sideways%22%3ETEXT%E3%81%AE%E3%83%9A%E3%83%BC%E3%82%B8%E3%80%81%E3%82%B9%E3%82%AF%E3%83%AD%E3%83%BC%E3%83%AB%E3%81%8C
<fantasai> Koji, looks like no support
<fantasai> Note that all properties are prefixed
<fantasai> -webkit-
<koji> I see, because you use vertical-lr
<koji> WebKit supports sideways correctly if vertical-rl
<koji> looks like
<koji> vertical-lr + sideways = mixed in WebKit, but
<koji> vertical-lr + sideways = sideways-right
<koji> So WebKit does have problems for CJK, not a problem for
Mongolian
fantasai: We have two different behaviors for the sideways keyword
in vertical-lr mode:
fantasai: Blink implements it as sideways-right,
fantasai: Webkit implements it as mixed,
florian: Since they're prefixed the same there should be no compat
hit.
fantasai: Yeah.
dbaron: We're not currently shipping our pref for text-orientation.
<koji> Mongolian needs sideways-right anyway, so I guess option 1
works better than option 1?
smfr: We did this for Japanese, so that's probably just a bug.
<fantasai> koji, does content depend on unprefixed
'text-orientation: sideways'?
<koji> fantasai: don't have data
fantasai: I feel like we're leaning towards option 1 or 4.
fantasai: There seems like a decent likelihood that we won't have
sideways-left for a while, so I think it's at risk of
being dropped, what happens to sideways in that case as
we may have web compat.
florian: Again, it's only in prefixed properties for compat.
florian: Also, it's mainly in books, etc. so less likelihood of
automatic prefixers.
florian: Maybe we should drop them now,
dbaron: Another option is to keep sideways-left/right and put
vertical-lr at risk.
fantasai: Seems less likely to drop vertical-lr.
smfr: I don't think I'd prefer that.
tantek: What is the usecase for 2 vs 3 keywords?
fantasai: [shows the different examples again]
fantasai: It's captions on tables or image, and you want to put
the block ordering in English.
fantasai: The other options are for CJK languages, it doesn't make
sense for English.
tantek: So for horizontal text written vertically that's the main
use case for sideways?
florian: Yes.
<koji> tantek: sideways-left is for English, but sideways-right is
used in CJK and Mongolian too
<koji> and most of the use cases can be achieved by
transform:rotate(180deg)
<koji> So I'm not positive to bring in the complexity
sideways-left has
SteveZ: It's not easy as you say, what if you want it different on
the left than on the right of the document?
fantasai: You would change the writing-mode only.
fantasai: The use cases for sideways-left are not that strong,
fantasai: but to have sideways, you have to have both
sideways-right and sideways-left.
tantek: They're not strong, but there are use cases?
fantasai: Yes, in books, with tabs in the corner that are rotated,
etc.
tantek: Are there any use cases for non-90 degree angles?
fantasai: Not currently.
fantasai: On a related note, we may want to change the keywords to
sideways-rl and sideways-lr to match writing-mode
keywords.
florian: I don't think that is better.
florian: Typically when embedding a foreign language in Japanese
you normally do sideways-right.
fantasai: But there are examples of both.
tantek: What is the easiest one for authors to remember, if it
doesn't actually map to vertical-lr then we probably
shouldn't change it.
dbaron: Let's pick an option before moving onto the naming.
fantasai: [crosses off number 3]
smfr: When we unprefix, we could change the behavior.
fantasai: I think you could change it now, because people aren't
really depending on sideways-right in vertical-lr mode.
fantasai: [explains options again]
smfr: Just spec what people want and we'll change our
implementation.
Working Group says to keep 4: Implement sideways correctly,
smfr: File those bugs and we'll go fix them.
RESOLVED: Clarify the spec to correctly explain how to implement
sideways.
RESOLVED: And how to not implement sideways
RESOLVED: Don't mark vertical-lr at risk
koji: Anymore issues?
<koji> Are there time for issue 10?
auto-multicol and orthogonal flows
----------------------------------
fantasai: Issue 10.
fantasai: Let's say you have a vertical block and start writing,
and the block gets longer and longer.
fantasai: Because we only paginate in one direction, when you
print it chops off the overflow to the side.
fantasai: However, if you support multicol, when you print the
spec requires that overflow gets broken into columns
that then flow in the paging direction.
fantasai: This is good because you have no data loss and this will
allow ebooks to still work as well.
ChrisL: You said this as though it was magic, but does the
stylesheet have this, or does the UA do this?
fantasai: The spec currently says that this needs to happen if you
overflow, so you would need to put it into multicolumn.
Rossen: We had this behavior in IE6/7 when you have vertical
inside of horizontal, our printing would do what you are
saying.
Rossen: We didn't emulate this in later versions, it wasn't
technically too difficult to do but in my opinion if we
need to have this it would be easier to do the magic
behavior that ChrisL stated,
Rossen: where when we're paginating, that would allow us to keep
the layout.
fantasai: I'm not recommending this for just printing.
SteveZ: Isn't this where you would want to do overflow: fragment?
tabatkins: Sure, multicol was just the way to get the behavior.
fantasai: You don't want copies of the container with it's
decorations.
fantasai: This is just for autosizing.
SteveZ: I would still need to set a height.
dbaron: This seems way too magical.
dbaron: I would prefer to do it in simple ways that they can know
how to set it up.
florian: On the other hand if you're testing on your screen and
don't hit this, that causes problems.
smfr: There are other ways to cause these issues.
plinss: I would like to see a general solution to clipping content
to overflow.
Bert: It's not overflowing, the height is auto - you have infinite
space in the block direction.
fantasai: You don't want to set the height to vh, because you'll
cause overflow in the block direction as well
SteveZ: Then I agree this is way too magical.
Rossen: Also this is really rare.
fantasai: The author doesn't print their website ever, it's the
user.
fantasai: That's why we set to shrink wrap to the viewport height,
fantasai: and that causes things to wrap and end up overflowing.
SteveZ: I agree that multicol is good solution, but I would prefer
to use overflow: fragment.
plinss: I like the effect, and what you're trying to do with it,
but I don't like the magic and trying to explain
pagination using multicol.
fantasai: We normally just tile sideways overflow, if we print it
at all, but here you don't want to tile it as you'll cut
stuff in half.
plinss: I just wish we had a better way of explaining pagination.
plinss: It feels like overflow: fragmentation is the right way to
take this, but we need to mature that space.
fantasai: Multicol and fragment are very similar, but multicol
will provide you with the backgrounds and borders you
want.
plinss: I want a better general explanation of this.
<dauwhe> +1 to plinss
florian: We've been using multicol as a type of exotic layout, but
in this case it is very fundamental in common layouts.
florian: The type of behavior it gets you is quite fundamental.
plinss: Again, the behavior is the correct one, but I don't want
it just using multicol under the hood. I want a general
set of primitives that explains pagination that people can
trigger.
fantasai: This is only triggered in an orthogonal flow.
Rossen: The spec encourages to set height.
SteveZ: I would like to have it work on all heights.
fantasai: [draws diagrams showing calculations of heights of cols
in an orthogonal flow]
SteveZ: If I print that and I've set the orthogonal flow to 1vh.
fantasai: You can't because you can't split the line box.
fantasai: We don't have the capability of having variable width
columns.
ChrisL: This is the type of thing that authors can't control.
fantasai: They can set the properties themselves and control this,
this is only for situations where everything is auto.
dbaron: This is making me think things are getting more and more
complex, for example I'm considering not investing on grid
as it keeps evolving.
dbaron: I'm starting to regret working on writing-modes, as I want
to be able to ship stuff that are valuable.
tabatkins: This is not getting more complex, we're just starting
to actually document everything instead of just saying
"magic".
tabatkins: This is a common thing that people hit.
florian: Yes, mixed modes are very common in Japanese.
tabatkins: I understand your frustration.
fantasai: The spec even says what to do if you don't have support
for multicol.
rossen: In the current Japanese printed world, where you're saying
most of them have mixed writing modes, I've never seen them.
SteveZ: The most likely place you'll see this is in English text
quoting Japanese text.
SteveZ: The real problem I think is between the switch of captions.
Rossen: Again, these are small chunks, not long long flows of text.
smfr: Are we trying to do this in L3, or can we defer this until
later?
fantasai: I think that's ok, but we may run into a few edge cases
with this.
rossen: I've discussed this case so many times and yet I've never
seen it, it's always something small.
<Bert> (Image from a ftf in 2012:
http://www.w3.org/Talks/2012/0509-CSS-ftf/all.htm#challenge5 )
fantasai: [draws a sample Japanese magazine layout]
fantasai: [talks about how the publishers adjust the layout and
content to make it work just right]
fantasai: We don't see what happens when you mess with the layout
or change the screen size.
fantasai: We should decide on what to do,
fantasai: We should make it so that it doesn't clip the content.
rossen: Is anyone asking for this? If this was a very big painful
point the entire Japanese publishing would let us know.
fantasai: Sure we can defer this, but we should solve this problem.
rossen: I'm not saying that. We're about to add a bunch of magic
that won't be trivial to implement and cause interop
issues on something that we aren't commonly told is an
actual issue.
fantasai: [shows another use case]
SteveZ: I think vh is the wrong thing to use for the line length,
I think it would be better to use Xchars in the default
font.
rossen: I'll add to this, when I implemented orthogonal flows in
IE8, when you have a mixed flow and let's say the body has
a margin of 100vh you will automatically have a scrollbar
even if you don't overflow.
rossen: Again, I've never heard from people about this problem
though.
fantasai: I think that ultimately the author should select the
correct column height.
SteveZ: No one can read that, though.
SteveZ: My memory, and I can't remember where from, is between
14-16 ems for Japanese.
fantasai: As a spec author I'm not going to pick an arbitrary set
of numbers for font sizes.
tabatkins: She's trying to just provide the same capability for
vertical text as horizontal text.
plinss: The more I think about this, the more I think this is the
right solution for orthogonal flows especially when you
have N levels deep. All my other reservations stand on
their own, but on this one I think this is the best
solution for this.
rossen: What happens if it's a scroller, would you still do
multicol?
rossen: I have a a div from overflow: visible to overflow: scroll.
florian: It would make sense to remove the multicol.
rossen: Well that's more fairy dust and magic.
fantasai: This will only trigger if you have height:auto and thus
can grow in that infinite direction; a scroller will
have a set height, so won't trigger this.
plinss: What is stopping the line from being one long line,
something has to be causing it to wrap.
fantasai: You don't want to have any line of text that is longer
than your viewport. Otherwise you have to scroll back
and forth to read the text.
tabatkins: That's the behavior if you don't support multicol or
you have line breaks (pointing at css3 multicol
example).
SteveZ: I still think there are enough unanswered questions that
it should be deferred.
florian: There is value in shipping this, if not shipping anything
at all.
SteveZ: But you're not providing anything valuable.
fantasai: In the case of fixed height, we're trying to avoid
overflowing, which is the whole point of this.
SteveZ: All you're doing is coming up with a height for the first
block if no height is set.
Bert: You can turn it into a fixed height and multicol.
glazou: This discussion is going no where, let's wrap up.
fantasai: I think everyone can agree to add this to the at risk
list in the spec, we can agree with that.
rossen: Yep.
fantasai: We'll see where we are.
fantasai: If stuff ships and we don't have this, then we'll defer
it.
<koji> Thank you all and sorry for making lunch late.
<gregwhitworth> koji: no problem, thank you for staying up late!!!
Received on Saturday, 30 May 2015 01:23:00 UTC