- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 2 Jul 2015 06:30:22 -0400
- To: www-style@w3.org
css-logical-properties
----------------------
- Gecko now also has plans to ship some of css-logical-properties.
- Mozilla clarified the pieces they'll be shipping.
fixed z-index interop issue
---------------------------
- RESOLVED: Make position: fixed a full stacking context
- Rossen will write the text change in place it in the Positioning
spec. Bert will then take the same text and add it as an
errata to CSS 2.
Aggregating CSS modules
-----------------------
- The ability to create a big document listing all the modules is
on the bikeshed issues list and therefore will happen at some
point.
Language specific support for hyphenation and justification
-----------------------------------------------------------
- Everyone agreed that there was a use case for this and that
there are definitely times where you may want to style
differently depending on if you can hyphenate text.
- There were concerns about the performance implications of
checking for hyphenation support, but most group members
believed there would be no significant change in performance.
- It was concluded that, though there are use cases, it wasn't a
high enough priority for implementation. Florian will keep the
text in case the priorities change in the future.
css-text-decor
--------------
- There were two primary issues raised for underlines in
css-text-decor
1. Do we allow auto to combine with left|right
2. If left | right is specified alone, is the behavior in
horizontal text under or auto
- The proposed syntax seemed okay to everyone, but is dependent on
the final solution to the above questions.
- No consensus was reached and discussion will continue on the
mailing list.
Splitting CSS-speech
--------------------
- There was some doubt as to if there would be any interest in
CSS-speech, even if it is cut down to just speak and speak-as
in the first draft.
- glazou will be reaching out to get more context to if it's even
possible to break out speak and speak-as.
Display WD
----------
- RESOLVED: New WD for Display
===== FULL MINUTES BELOW =======
Present:
Rossen Atanassov
Tab Atkins
David Baron
Bert Bos
Bo Campbell
Tantek Çelik
Alex Critchfield
Elika Etemad
Simon Fraser
Daniel Glazman
Koji Ishii
Dael Jackson
Chris Lilley
Peter Linss
Anton Prowse
Matt Rakow
Florian Rivoal
Simon Sapin
Anton Stearns
Lea Verou
Greg Whitworth
Regrets:
Sonja Bonic
Tony Graham
Brad Kemper
Michael Miller
scribe: dael
css-logical-properties
----------------------
glazou: Let's try to start
glazou: There were a few additions. I saw a message from Florian
about the backlog and one from Koji.
SimonSapin: I had one. Gecko is intending to ship
css-logical-properties which isn't a WD yet, it's full
of issues.
glazou: And you'll ship the full of issues?
SimonSapin: I'm not sure exactly what.
Florian: Unprefixed?
<SimonSapin> https://groups.google.com/d/msg/mozilla.dev.platform/zQgw_4WeBkc/oyVZ5-k1D6cJ
fantasai: If any issues are on www-style with Mozilla's proposed
resolution somewhere it's good to have that. Otherwise
I'll get around to connecting everything later.
glazou: Was that a question or an announcement?
SimonSapin: I wanted to bring to the group's attention. I don't
know if it's a problem to ship early.
dbaron: The pieces we're planning on shipping aren't the pieces
with the problems. We're not shipping the shorthand on
logical. I think we're shipping margin-padding, border-*
and one other, I think.
glazou: Behind a flag?
dbaron: No. Only longhands.
dbaron: It's been behind a flag for a year.
Florian: If you want to ship, why not help finish the spec first
to be sure things won't break. I think that's what we
generally said we'd be doing.
dbaron: Fundamentally because we're the last browser to ship this,
i.e. vertical text support, and shipping it depends on
logical properties for us.
dbaron: And we'd really like to get it shipped.
glazou: We're not going to do this right discussion right now.
Thanks for the announcement. I suggest discussing the
future of the spec on the ML.
glazou: Anything else before we really start?
<dbaron> the logical props we have are margin-*, border-*,
padding-*, top/right/bottom/left, (min-/max-/)width/height
* fantasai will try to set aside some time to finish up the fpwd,
has a couple things higher in the queue
fixed z-index interop issue
---------------------------
gregwhitworth: Is dbaron there?
dbaron: Yes.
gregwhitworth: We've been pushing this off a bit. Blink, Webkit
and Edge basically give anything with z-index its
own layer but the spec says it should work like
abspos and not get a new layer. We want to change
the spec so that it represents the reality of the
other browsers. Marco has been seeing issue in
mobile.
gregwhitworth: I want to get your input and see if you're against
it.
smfr: You mean position: fixed getting a stacking context?
gregwhitworth: position: fixed, not z-index, thank you.
dbaron: I think I'm okay with it.
Rossen: It's worth mentioning that I had...when we pushed this
early in Edge development phases I added this behind a
flag to see if anyone complains. We didn't hear any but we
do know of a number of pages that will be broken when the
opposite is broken,; when fixed position don't create
stacking.
Rossen: The interesting bit of information is during Sydney F2F
someone from Chrome, I think Rick Byers, said they want to
revert and support a partial context on z-index. I'm okay
either way, with our implementation both are possible, but
I'd prefer to lock on one of those.
Rossen: If anyone from Chrome can comment that would be great.
TabAtkins: I can ask, but I think it's that our recent
improvements make it possible to go back to partial. I
don't think there's anything wrong with full stacking
context.
smfr: I'd prefer we maintain a full stacking. Our painting can't
deal with interweaving.
Rossen: So if we decide to support partial, you won't be able to
for technical reasons.
smfr: We've been shipping with fixed for 2 years so going back
would be a compat risk for us.
smfr: So it sounds like we're back to the question as to if Gecko
will make position: fixed create a stacking context.
dbaron: I think it's fine given that it's for compat.
Florian: As an author I think this is sufficiently confusing and
having the semi-stacking makes it worse. If we can avoid
that, it's better.
gregwhitworth: So can we resolve on this? I don't know if we put
it in 2.2 or what, but can we call for resolution?
glazou: If everyone agrees to implement it the same thing we can
resolve.
Rossen: I missed it, my connection dropped. Did we resolved to
make position: fixed a full stacking context, always?
Florian: We seemed to be about to.
gregwhitworth: It seems there's no disagreement. dbaron is saying
it's okay. If no one is against it I say we resolve.
Rossen: The only reason I brought it up is there was the
implementation consideration from Chrome and I don't want
to have the same conversation in 6 months with the
opposite argument.
TabAtkins: There's nothing technical making stacking context hard.
There's something technical with making partial hard,
but full isn't a technical issue. I think we'll be fine.
Rossen: Sounds great. So we can resolve on it and that's it.
glazou: Objections?
smfr: Clarification: If a position: fixed element has a
transformed ancestor and it doesn't behave in a fixed way,
does this apply?
smfr: I want to clarify if it's the position: fixed itself or
having the containing block be the view port.
TabAtkins: I think it's just position: fixed.
smfr: Okay, that's fine.
Rossen: That sounds really good. Tying it down is better than
looking up ancestry.
RESOLVED: Make position: fixed a full stacking context
gregwhitworth: So how does this make it into the spec?
Rossen: I can add it to Position level 3.
fantasai: It needs to go into level 2. We should action Bert to
update.
<Bert> (Is it just a clarification?)
antonp: Isn't this already in level 2?
Rossen: I'm not sure why you think that's the case, but it's not
true.
fantasai: In 2.1 position: fixed is considered a stuck category of
abspos.
antonp: I think I'm thinking of something else. I think I'm wrong.
I'll write to the list if I correct myself, but I think
I'm wrong.
Bert: For CSS 2 does it need a change?
Rossen: I think there's agreement you have to have a note in
CSS 2.2. That was fantasai's argument and I don't have an
opinion. I will add the requirement to CSS 3 positioning.
fantasai: It needs to go into both.
ACTION Rossen add position: fixed as s full stacking context to
positioning
<trackbot> Created ACTION-698
Bert: I can look at Rossen's text and create an errata
Rossen: It'll be one sentence and we can use it in both.
ACTION Bert to take Rossen's text and export it to level 2
<trackbot> Created ACTION-699
<rbyers> Rossen: IIRC it was vollick who said he felt guilty about
us insisting on a full stacking context for
position:fixed now that our implementation no longer
requires it. I.e. we recognized a fundamental flaw in
WebKit/blink compositing architecture (that causes
correctness issues elsewhere) and are close to finally
eliminating it.
Aggregating CSS modules
-----------------------
<glazou> https://lists.w3.org/Archives/Public/www-style/2015Jun/0160.html
glazou: We started the discussion, but I'm not sure we went far.
astearns: I started it to prod plinss and TabAtkins.
TabAtkins: We keep being lazy about creating the index of all
things in CSS. Altering bikeshed so that it can make a
huge document is something I haven't done. I've been
doing bikeshed issues for a bit and I might get there.
Rossen: SVG has been asking for the same thing. They've been
waiting for this so they can switch to bikeshed.
TabAtkins: It'll be on my list. I think I have it as an issue.
Language specific support for hyphenation and justification
-----------------------------------------------------------
Florian: This is something I was wondering about. We have
@supports, but it doesn't quite work for hyphenation
because when the browser impl hyphenation it doesn't do
it for all the languages in the world.
Florian: If you think something is ugly without hyphenation, you
need to know if it supports hyphenation on the language
you're using for the element, to decide if you want to
use narrow columns or justification for example.
Florian: I'm not saying that's always enough to give nice
hyphenation, but it's a datapoint that's useful. I was
thinking we might want to introduce either a special
syntax in @supports or a pseudo class that you can tag
onto any element.
Florian: Based on the language the element uses, if it's one the
browser can hyphenate then the class matches and you
use that to style.
Florian: A second part is if you want to turn on justification but
only if the browser can do it nicely, which might mean
hyphens for some languages, but not all. Trying to detect
it sounds useful, but it's hard to tell what 'nice' means.
Florian: I think they hyphenation case is less fuzzy. 'If it's
supported' is non-ambiguous.
TabAtkins: I agree that multiple ambiguous hints aren't something
we want. The hyphenation is unambiguous. It sounds
reasonable and I see the use case.
* fantasai is unsure this is that important to solve atm
* fantasai is therefore unsure it's worth the work/complexity to
add
Florian: The difference between the syntaxes is if you're using
@supports you can inside that have any number of rules
and combine. What's nicer with a pseudo class, in
@supports you have to ask about one language specifically.
Florian: That makes me lean toward the pseudo class. You have
multiple declarations, just on a rule block.
TabAtkins: This is classically a MQ type thing. That seems to be
more natural, but I have to think on it.
astearns: I'm not entirely sure that's enough justification for
this new feature. If a UA doesn't support a language for
hyphenation, maybe that's a bug. As UA gets more
sophisticated the need diminishes.
Florian: I doubt we'll reach a point where all UA support hyphens
for all languages. It's too large a set, almost infinite.
astearns: So you're talking about a stylesheet for near infinite
rules?
Florian: If you're creating something where you expect a lang tag
and you want to go with a different layout depending on
what's supported, we should be able to do that. There
won't be a browser that knows all local languages.
<dbaron> https://developer.mozilla.org/en-US/docs/Web/CSS/hyphens#Notes_on_supported_languages_2
Rossen: I'm a bit hesitant for a feature like this. When we were
adding conditional language abilities for windows apps, we
had similar problems where content written for RTL
languages or hosted in RTL it needed to adapt properly so
on/off buttons are right. Hyphenation in that respect, I
don't see as an outlier in language-specific behavior.
Rossen: It's also a minor use case. Making such a huge exception
for a minor feature is a stretch.
Rossen: The fallback here isn't really that bad. The third thing I
wanted to point out, we have a service that we use which
is shared across many components. Simply booting the
service is quite costly so doing it per element is crazy.
glazou: Doing this on a per element basis, as soon as you have the
info for a given language you can cache. You don't
hyphenate differently between elements. As soon as the
info is acquired you have it for the whole session.
Rossen: Does that go for mixed language?
glazou: This is related to my question. Florian mentioned the
pseudo class, but does it take an argument?
Florian: It matches the language of the element. No argument.
glazou: I don't see the problem. In 99.9% of cases the language
will be the same.
Florian: And if you have a bunch of languages this isn't more
costly. If we didn't have it you would apply hyphens and
have to turn on the engine anyway.
glazou: I understand the performance concern, but we should stick
to the usefulness of the feature. There's an issue there.
Florian: I don't think it's majorly useful, but the same is true
of hyphenation. Hyphenation itself is more difficult to
use if you can't know if you have it. You can't use
@supports, so you're stuck right now.
Florian: Narrow columns without hyphenation can be ugly so it's
reasonable.
TabAtkins: There are layout types you only want with hyphenation.
Florian: And you only want this if you have a language that
doesn't need hyphenation or if you can have hyphenation.
We can have the browser tag if it doesn't need it.
glazou: So the official French typographic rules, which we've used
in the past, I've seen some prose about not using
hyphenation in that case. But the use case exists.
Florian: You mean not using justification if there's not
hyphenation?
glazou: Yes.
Rossen: Can you find a reference to that?
glazou: Yes, it's at home, but I will.
glazou: I'm not so sure the cost of implementation for this is
expensive, I think it's straight forward. It could solve a
case in some languages for layout. I feel, personally,
that we should investigate.
glazou: What do others think?
Rossen: From implementor's POV this will be low on the stack. I
can see the completeness argument from Florian. If there
are use cases that can hit somewhere...but cost to benefit
is off.
fantasai: I agree with Rossen.
glazou: Other implementors?
<dbaron> I don't have a strong opinion either way.
TabAtkins: I'm not able to speak on this now.
smfr: I'm not aware we've had any requests on this so I think it's
low priority.
glazou: Florian would you keep some prose under the radar for now?
Florian: Yes, I can see how it's not high priority, even though
it's not wrong. I'll keep the text.
css-text-decor
--------------
<glazou> https://lists.w3.org/Archives/Public/www-style/2015May/0153.html
fantasai: Currently we have an auto value and an under value and a
right value.
fantasai: If we look at the spec [link]...
<fantasai> http://dev.w3.org/csswg/css-text-decor-3/#text-underline-position-property
fantasai: You can combine under with left or right so you can have
different behavior from vertical and left and right. The
feedback we got was that we want to have...there's a
suggestion the UA stylesheet should have a rule that
sets the underline to the correct side for Chinese and
Japanese.
fantasai: That's in the spec as a recommendation. But because you
can only combine right with under it causes a problem.
The suggestion is to let auto and under both be combined
with left or right.
<dbaron> Japanese and Korean on right, Chinese on left, no?
fantasai: dbaron is correct
<Bert> (Maybe there is way to generalize this: provide alternative
styles based on whether each of them can deliver a certain
quality, where "quality" can be an aggregate or a set of
detailed typographic measurements...)
koji: I'm not clear about what the semantics is.
koji: I'm unclear about how to interpret another value.
fantasai: That is another issue. If left or right is specified
without the other keyword, what do we do?
koji: Or if under is specified, is it left or right?
fantasai: It's just going to be left.
Rossen: And under start won't work?
fantasai: It has less to do with start and end of block and more
with text orientation. For example, Mongolian, the
underline will be on the right side, even if it's the
end side.
fantasai: It's the end side on CJK. under if you specify it by
itself, it means it goes on that side of the text. left
and right give a direction, either the left or right
side.
Rossen: In that case, I'm okay with auto. It's magic enough for
people to get it from the get go. It's better off to be
left as magic.
glazou: Other opinions?
glazou: Any disagreement? Objection?
koji: I'm okay with the syntax, but from the original proposal I
can't read what they're expectation is for some of the
values. I want to confirm that they think it means.
fantasai: There's two issues. [types]
<fantasai> 1. Do we allow auto to combine with left|right
<fantasai> 2. If left | right is specified alone, is the behavior
in horizontal text under or auto
fantasai: I'm guessing it should be auto since that's the initial
value.
koji: Does that imply when under is specified left or right is
auto?
fantasai: Under has a meaning that isn't left or right, it means
it's on the underside which depends on the text
orientation.
fantasai: Most cases it will be left, but in sideways-left it
would be right.
koji: Japanese is right.
fantasai: Yes.
Rossen: When is left and right used when auto does it when it's
needed?
fantasai: It doesn't.
koji: auto applies only for horizontal, I think is what she's
saying.
fantasai: We discussed having auto adjust based on the language
and we decided not to have it change based on the
language.
fantasai: Let's all look at the word alphabetic in the spec.
fantasai: There's a p and the line crosses the tail. That side of
the text is the underside. If we rotate the text 90
counterclockwise, the underline is on the right side.
clockwise it's on the left.
fantasai: Auto puts the underline on the side of the text that's
the bottom after you rotate the text. Since Japanese and
Korean have their typesetting rule place it on the right
side of the text, we added a UA rule that says for those
two languages change the value so that in vertical text
it is on the right side.
koji: We allow auto to adjust between CJK and non-CJK for
horizontal. I also requested not to have UA stylesheets
request what you want. Like that you said in the mailing
list.
glazou: Among the two people discussing, I'm not seeing consensus.
I don't know what to do with your discussion now.
koji: I think we can resolve syntax now. We can continue the
semantics discussion on the ML.
glazou: fantasai?
fantasai: I think that that's fine.
Rossen: Is the ML discussion happening?
fantasai: One thing that's confusing is if we change the meaning
of auto to switch sides, not just adjust the position.
It doesn't flip to the other side of the text, it's
always on the under side of the text. If we change auto
to also place on the over side it doesn't make sense to
combine it anymore.
koji: I asked for clarification yesterday on the list. Maybe it's
worth waiting a bit more to see if the discussion continues.
glazou: Okay. Done deal.
koji: We can resolve the syntax change.
fantasai: I think if we're changing the semantics of auto, we may
want to rethink the syntax.
koji: Okay.
Splitting CSS-speech
--------------------
<glazou> https://lists.w3.org/Archives/Public/www-style/2015Jun/0347.html
fantasai: I was thinking speak and speak-as are something we would
encourage general authors to us since it lets them
control is some text is visible to speech. There's
examples such as websites will position stuff off to the
weeds so that it's there for speech but you don't want
it for visual people. speak could override that so you
do display: none and speak: normal and it overrides it.
fantasai: That seems like it would be generally useful and be
implementable without much interaction with the speech
rendering. It seems like that might be useful for
general authors, while styling the voice-rate and other
things in CSS speech, they're interesting, but it's
unlikely authors will take advantage of them in a useful
way.
<tantek> Big question here is who are the implementers that have
any interest at all?
<tantek> Without indication of even a hint of implementer interest
I'd say it's too low a priority to bother with group time
on.
<tantek> Even *interest* nevermind code.
<bkardell_> what agent supports css-speech?
smfr: I think tantek is making a useful point that there's such
little impl it might not be worth talking about.
fantasai: I don't think there's interest in the rest of
css-speech, but I think speak and speak-as will be
useful.
<tantek> If even a single implementer speakers up indicating
interest in impl, then let's re-assess
fantasai: And might be interesting to implementers, if they were
not buried in the rest of speech
<bkardell> it seems to me leonie watson recently told me she
couldn't find any if that is worth anything
glazou: I'm not sure we're the best place to know about special
application tools. I suggest pinging Daniel Weck. He was
the author and will know about where it's used.
glazou: I'd like him contacted before we move on.
<bkardell> glazou: I can bring it up in a11y task force if that is
helpful
<tantek> Otherwise not worth the time. But agreed with glazou - ok
to ask around.
bcampbell: I'd be interested in understanding this further and
getting opinions from screen reader users.
glazou: fantasai do you want me to take an action to contact?
fantasai: I'm mostly interested in what the browsers are doing
right now. It seems it would be useful for a11y.
ACTION glazou contact Daniel Weck to see if there's any evolution
on speak and speak-as so we can see if we can extract it.
<trackbot> Created ACTION-700
<tantek> Documentation of those use cases would be a good start.
<tantek> That fantasai mentioned
<fantasai> tantek, look on the web for text-indent:
<huge-negative-length>
<tantek> fantasai, big neg text-indent is a hack for all kinds of
crap. SEO nonsense etc.
<fantasai> tantek: ok, on a page that isn't doing SEO crap :)
<tantek> Lol
Display WD
----------
<glazou> https://lists.w3.org/Archives/Public/www-style/2015Jun/0346.html
glazou: There was issues and a publication request.
TabAtkins: We only have two minutes left.
fantasai: I suggest we publish and deal with issues later.
glazou: Objections?
<ChrisL> yes!
<ChrisL> +1 to publish
RESOLVED: New WD for Display
glazou: Thanks everyone. Sorry if the first day of webex wasn't
perfect.
Received on Thursday, 2 July 2015 10:31:25 UTC