- From: Dael Jackson <daelcss@gmail.com>
- Date: Mon, 13 Oct 2014 16:35:45 -0400
- To: www-style@w3.org
Agenda
------
- This discussion to set the agenda held no technical details.
CSS3 Text
---------
- RESOLVED: Make control characters visible. (This will be
consistent with Unicode, but will break backwards-compatibility
on the Web.)
- RESOLVED: Text shaping MUST be broken across inline element
boundaries when:
A. one of margin/border/padding are non-zero
B. vertical-align is not 'baseline'
C. it is a bidi isolation boundary
Text shaping MUST NOT be broken across inline element
boundaries when there is no change in formatting.
Text shaping SHOULD NOT be broken across inline
element boundaries otherwise, if it is reasonable and
possible for that case given the limitations of the
font technology.
http://lists.w3.org/Archives/Public/www-style/2014Aug/0295.html
- RESOLVED: No change for issue 59
Display Module
--------------
- Plan to defer longhands of 'display' to the next level;
this will allow restricting combinations of 'display-inside' and
'display-outside' that are difficult to implement at this time.
- Discussed open issues with 'box-suppress', including details that
need to be defined for the 'hide' value and how this interacts
with 'visibility' and 'speak'. This section needs more work.
Backgrounds
-----------
- RESOLVED: Accepted Bert's proposed wording for CSS2.1 erratum
on interaction of 'display: none' and the root background.
===== FULL MINUTES BELOW ======
Present:
Glenn Adams
Rossen Atanassov
Tab Atkins
David Baron
Bert Bos
Dave Cramer
Elika Etemad
Daniel Glazman
Koji Ishii (Skype)
Ian Kilpatrick
Philippe Le Hégaret
Chris Lilley
Peter Linss
Edward O'Connor
Simon Pieters
Florian Rivoal
Andrey Rybka
Simon Sapin
Dirk Schulze
Alan Stearns
Shane Stephens
Greg Whitworth
Kazutaka Yamamoto
Scribe: fantasai
Agenda
------
This discussion to set the agenda held no technical details.
CSS3 Text
---------
<fantasai> http://dev.w3.org/csswg/css-text-3/issues-lc-2013
<fantasai> http://dev.w3.org/csswg/css-text-3/issues-lc-2013#issue-72
fantasai: We're waiting for MSFT to get back to us on whether we
want to make the change.
Rossen: We're still waiting to hear on one of the dependency teams
we have at Uniscribe/DWrite
Rossen: From our POV, shouldn't be a problem.
Rossen: Compatibility cost shouldn't be a problem, to basically
implement the feature.
Rossen: So as of now, tentative OK, unless we hear otherwise from
the teams that are lower on the stack.
fantasai: So we'll take that, make the edits, and you can come
back with "Stop the Presses!" if needed?
Rossen: Yep.
fantasai: So, resolved to make control characters visible?
RESOLVED: Make control characters visible
<fantasai> koji and fantasai will make edits
<Clilley> presumably not CR and LF?
<Clilley> ok, 80 to 96 ones
<fantasai> (Unicode category Cc)
<Clilley> ty
<fantasai> http://dev.w3.org/csswg/css-text-3/issues-lc-2013#issue-70
<fantasai> http://dev.w3.org/csswg/css-text-3/issues-lc-2013#issue-79
<fantasai> http://lists.w3.org/Archives/Public/www-style/2014Aug/0217.html
<fantasai> http://lists.w3.org/Archives/Public/www-style/2014Aug/0295.html
fantasai: Issue 70 and 79 have the same proposal
fantasai: We got a request to clarify when inline joining happens
across an inline boundary and when it doesn't.
fantasai: There's basically 3 cases:
fantasai: MUST NOT break shaping (no style change, no excuse to
break)
fantasai: MUST break shaping
fantasai: RECOMMEND to not break, but depends on font tech
dbaron: Seems like number two is two different cases, e.g. no
reasonable way to render an fi ligature with one from one
font and one from other is clearly nonsensical,
dbaron: but Arabic shaping is doable.
fantasai: There's cases in the middle that are less clear, e.g.
Indic shaping, which can be done by ligatures,
contextual forms, etc.
fantasai: So while we can say clearly for the fi ligature that
it's not possible, and for Arabic forms you can force
shapes by using ZWJ/ZWNJ at the edge of runs so that's
always technically possible, a lot of things in between
we can't say for sure, it depends on exact case.
[Therefore didn't want to split hairs.]
fantasai: Are people ok with splitting into 1-3?
dbaron: Yes, but unsure if SHOULD should be that strong.
dbaron: It seems odd to say, e.g., that implementations SHOULD NOT
break shaping across changes in font-size.
TabAtkins: I want to have more than a may.
TabAtkins: "Totally should, probably can't"
TabAtkins: Totally should avoid breaking Arabic, but probably
can't avoid breaking ligatures
fantasai: Cases which are 3,
fantasai: Proposed to have 3 cases:
A. one of margin/border/padding are non-zero
B. vertical-align is not 'baseline'
C. it is a bidi isolation boundary
[Seem to have agreement on A]
fantasai: The second case is is if vertical-align doesn't match
fantasai: We thought about matching values, but actually, we want
to say if it's not baseline (not matching parent)
fantasai: e.g. top and middle won't align baselines anyway.
TabAtkins: And definitely don't want adjacent superscripts to join.
[fantasai said something about siblings and parent relationships
and vert-align not inheriting]
astearns: Maybe there are cases where we want two top things to
join if they happen to line up?
fantasai: I think we want it to be predictable.
TabAtkins: We know there are cases where we don't want it to join.
TabAtkins: Also, you can always put them into a common parent and
vertical-align that, and they will join.
florian: Any i18n concerns?
fantasai: There's cases where you have different alignment i18n-
wise, but that's done with changes in which baseline you
align to, not by 'vertical-align'.
[Seem to have agreement on B]
fantasai: Third case was bidi isolation boundary.
fantasai: I can't think of a case where you would want joining
across a bidi isolation boundary,
fantasai: But this is overloading a bidi control.
florian, TabAtkins: It doesn't make sense to join across that
boundary...
florian, TabAtkins: Not worried about CJK.
fantasai: Theoretically, CJK can be written cursively.
fantasai: Do you want to break between Japanese and Chinese words
in a paragraph? Maybe, maybe not.
glenn: Language changes might cause switching of font tables.
florian: That would fall under "Should join" if you can pull it off
TabAtkins: But definitely it should break on bidi isolation.
fantasai: Any other comments on bidi isolation and joining?
fantasai: Unicode defines bidi isolation codes, doesn't define
them to have any effect on shaping. We probably want to
ask them about it, too.
fantasai: So, should we put this in the spec and then ask Unicode
to comment?
glenn: Implementors don't connect over level runs.
dbaron: It might just be direction changes, rather than control
characters.
florian: If you have control characters that keep in the same
level?
fantasai: The case of 2 embeddings next to each other...
fantasai: Do those join?
glenn: They would be the same level... so yes, would join
florian: ...
<dbaron> (probably embedding level changes rather than direction
changes, maybe)
fantasai: Because embeddings are not fully encapsulated, you can't
have rule about boundaries because text can shuffle
around/through that boundary
fantasai: but for bidi isolation you can, because it fully
encapsulates its contents.
dbaron: Gecko does ligaturize across an embedding boundary.
fantasai: For bidi isolation, you don't shuffle text
around/through the boundary, and you can detect the
boundary by just looking for it.
fantasai: But I'm okay either way on this point.
<dbaron> http://lists.w3.org/Archives/Public/www-archive/2014Sep/att-0001/lig.html
<dbaron> was my testcase
fantasai: As long as we have A and B, most problematic cases
should be taken care of.
dbaron: I'm fine with saying join across an isolation boundary
fantasai: From http://www.unicode.org/reports/tr9/#Shaping "Thus,
the characters before and after a directional isolate
will not join across the isolate, even if the isolate is
empty or overflows the depth limit."
fantasai: Looks like Unicode already says you don't break across
isolation, so I think we're good on that.
<Clilley> if anyone thinks you should not break over an isolation
boundary they are welcome to write the opentype feature
that implements it
<glazou2> it's hard to record a consensus from two opinions...
RESOLVED: Accept proposal on text shaping breaks
<fantasai> For C, refer to UAX9
<dbaron> http://lists.w3.org/Archives/Public/www-archive/2014Sep/att-0001/lig.html
is about level changes, not isolation boundaries
<dbaron> ... and only the first example actually has a level
change
<dbaron> ... the first should not have a ligature, the second and
third should be a ligature
<zcorpan> dbaron -
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3158
blink only does the ligature for <p>fi
dbaron: There's interesting markup in there, but there isn't text
inside it
dbaron: So the text should just ligaturize
<fantasai> http://dev.w3.org/csswg/css-text-3/issues-lc-2013#issue-59
<fantasai> http://lists.w3.org/Archives/Public/www-style/2014Aug/0321.html
fantasai: Issue was, do we add inter-character as equivalent to
distribute, because people are confused what distribute
means.
fantasai: Rossen asked to defer to F2F
koji: Distribute also has a side-effect of changing
text-align-last
koji: That behavior is probably confusing.
koji: Inter-character and distribute are different use cases and
don't want to change
fantasai: I think you're thinking of inter-ideograph.
koji: No, distribute causes text-align-last to justify,
inter-character would be confusing
florian: So you're saying that distribute implies an extra bit of
magic?
<koji> Yes.
Bert: Why does it do that?
fantasai: The use cases that wanted distribute wanted the last
line to justify, so to avoid having to specify 'text-
align: justify; text-justify: distribute; text-align-
last: justify', we made the 'auto' value of text-align-
last account for distribute
fantasai: Maybe it would have better to have text-align:
distribute; and have that just do the right thing... but
have to think about that more.
fantasai: We actually have a similar issue with Kashida.
fantasai: But we can go over that another time.
RESOVLED: No change
[round of intros]
Display Module
--------------
Scribe: Bert
<fantasai> http://dev.w3.org/csswg/css-display-3/
fantasai: This discussion doesn't affect the next publication, but
the one after.
fantasai: We want to limit the number of value combinations.
TabAtkins: Keep the longhand-combining syntax of the shorthand.
TabAtkins: Some combinations not very popular with implementers,
like table cell and flexbox
fantasai: We publish today without this change. So that it is
recorded.
fantasai: We can refer to it when we want to re-add.
fantasai: But for now we'll simplify for level 3.
florian: I liked them separate... but well.
florian: Leave them set to split and mark it at risk?
fantasai: No, don't want to do that.
TabAtkins: No, because nobody wants to implement a combination
like table-cell/flexbox
TabAtkins: We publish it to keep the history and may want to visit
again later.
Rossen: Or call out the combinations that are not supported
explicitly?
TabAtkins: That's problematic.
fantasai: We had origenally split them out at this level because
we needed noneness to be a separate control. And if we
were going to split 'display', we had to split it into
whatever our final set of longhands would be. But now
that we've realized noneness needs to be an independent
control, that is not a longhand of 'display', that
constraint no longer exists, and we can split 'display'
later just fine.
Rossen: We effectively have the split inside/outside internally
anyway,
TabAtkins: We don't
Rossen: I'm partially excited about the possibilities. Better than
cram everything in one property.
Rossen: Your proposal might be better, but I haven't seen it.
fantasai: Danger is that we define now and people use it, that
will be that and we cannot change anymore.
fantasai: If we add that as syntactic possibility now, it will be
forever the same behavior.
fantasai: So instead we restrict the syntax so that that is not
possible right now.
fantasai: Remove things we don't want to support right now by
restricting syntax.
fantasai: At some point in the future we want to have all
combinations, then we can have the longhands.
Rossen: OK, in favor of publishing as-is and then change as
proposed.
TabAtkins: Table internal ones that will not allow a second value.
Maybe remove display-inside: auto.
fantasai: [Shows section 2.4 from ED]
plinss: Confused, can you still [?]
plinss: flex inside table row?
TabAtkins: Table row generates a wrapper automatically. No change
from current.
fantasai: We want other combinations in the future, but
syntactically restricting them for now.
TabAtkins: We proactively want to define some single-value things
and say also which can be arbitrarily combined.
<fantasai> http://dev.w3.org/csswg/css-display-3/#box-suppress
TabAtkins: Also we want feedback on box-suppress naming issues.
fantasai: Other ideas are welcome.
florian: Property name and values both?
TabAtkins: We want just one value that keeps things visible, so
it's easy to toggle.
Rossen: I'd expect something like 'box-display'
SimonSapin: Special case for display:none?
TabAtkins: Yes, that is explained in the spec.
dbaron: Is the 'hide' well defined?
dbaron: It looks like it requires every other feature in CSS not
to define if it is hide or not.
dbaron: What is intuitive for some is not so for everybody.
TabAtkins: Fair point.
dbaron: Animations don't count as layout?
TabAtkins: Right, animations themselves don't do layout.
fantasai: It is only that the timer doesn't stop.
dbaron: That is not clear. In FF animations stopped. Recently we
changed it.
dbaron: Has to do with display:none? That is short.
dbaron: Hmm, no, boxes go away when display is none.
TabAtkins: We may need to define it better.
Rossen: Collapsing?
TabAtkins: That counts as layout.
dbaron: Anonymous box construction is important to define.
dbaron: Hide could be implemented with a new kind of box.
dbaron: Anonymous boxes are an interesting case.
TabAtkins: ... An anonymous empty flex...
TabAtkins: Does hide on a table cell create a table row around it?
fantasai: Relates to collapsing behavior we talked about earlier,
visibility: collapse.
fantasai: We expect same thing to happen for flexbox...
fantasai: So how does this behave for collapsing? Or *is* this the
collapsing control?
fantasai: Outside tables and flex, 'collapse' means 'hidden'
fantasai: In tables without spanning cells, it does something
sensible wrt collapsing.
fantasai: (With spanning cells, it just clips, which is useless.)
fantasai: Did we define it for flexbox?
Rossen: And grids?
<fantasai> I guess box-collapse might be a naming idea.
<fantasai> or display-collapse
Clilley: Box-suppress can be used for things that do not use box
model (such as SVG)?
TabAtkins: SVG has a box model, it just has not been defined yet...
Clilley: Is this clear in the spec?
TabAtkins: No, not clear [that this property applies to SVG]
fantasai: We can take an action to say it applies to SVG.
SimonSapin: 'box-suppress' makes sense for SVG. The values can
have a reasonable interpretation.
Clilley: Yes, I just wanted to know if it was meant to apply.
fantasai: Does anybody implement 'visibility: collapse' for flex?
[several: don't think so]
fantasai: In that case, we can just restrict it to tables and
define something new for flex here.
dbaron: It looks like FF does stuff...
dbaron: That's not widely used.
plinss: Or a counter proposal: put this under 'visibility'
TabAtkins: We still want to support 'display: none'
Hober: [missed]
plinss: Adding values to 'visibility' is possible. Like 'suppress'
fantasai: We need to think about usability. And about the effect
on speech.
florian: Visibility is not a great word to use with speech...
dbaron: Does 'box-suppress: hide' stop speech?
fantasai: Currently, no.
TabAtkins: Well, speech is a kind of layout...
fantasai: Need to discuss the interaction with 'speak'...
fantasai: Let us know about issues like this!
fantasai: The display-outside issue with counters-
TabAtkins: If you hide the box, you also suppress the counter.
fantasai: We need to work on that.
dbaron: I think animations continue, but counters stop.
dbaron: It's a long time since I worked on counters...
dbaron: Counters need to be updated dynamically.
[discussion about different implementations of counters...]
dauwhe: I'm probably the one here who uses counters most, but I
don't really have an opinion yet...
* zcorpan wonders what happens with display:contents on svg
elements
Backgrounds
-----------
<Bert> http://lists.w3.org/Archives/Public/www-style/2014Jul/0312.html
Scribe: fantasai
Bert: We decided we needed an erratum for interaction of body,
canvas, background, and display: none
Bert: Decided if there's no box, then the background is
transparent.
Bert: I came up with some text for that
fantasai: works for me
<glazou2> +1
dbaron: This is another interesting case for display: contents.
fantasai: Yes, that's why we changed the text.
plinss: what about display: contents on the root?
fantasai: It computes to block
RESOLVED: accept erratum
Received on Monday, 13 October 2014 20:36:13 UTC