- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 29 Aug 2017 17:55:48 -0400
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
CSS Display Level 3
-------------------
- RESOLVED: Leave 'display' syntax as-is for #1496
- RESOLVED: For 1246, inlinification of 'block flow' goes to
inline flow-root aka inline-block, blockfication of
inline flow-root & inline-block go to 'block'
- RESOLVED: For 1486, issue is moot because 1246 resolution was
reverted (above)
- RESOLVED: 'inline flow-root' serializes in getComputedStyle as
'inline-block'
- RESOLVED: Accept 1550 "flow never establishes a BFC. Instead,
all cases which require a BFC are handled by switching
the inner display type to flow-root at used value time
via becoming a formatting context."
- RESOLVED: Move "becoming a formatting context" section back to
css-contain, mark ruby/inline as open issues to figure
out.
CSS UI 4
--------
- RESOLVED: Put a note into "appearance" saying it's not ready to
implement, list the possible solutions discussed here,
ask impls which they want to do. (Issue #1250)
CSS Fonts 4
-----------
- RESOLVED: All font-* properties are reset by the font shorthand,
except font-presentation and font-synthesis.
CSS Counter Styles
------------------
- RESOLVED: Same resolution as yesterday (The language of a
counter is computed based on the language of the
element that the counter applies to at the point of
retrieval.)
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/paris-2017#topics
Scribe: nainar
CSS Display Level 3
===================
flow-root syntax
----------------
github: https://github.com/w3c/csswg-drafts/issues/1496
https://github.com/w3c/csswg-drafts/issues/1246
https://github.com/w3c/csswg-drafts/issues/1486
TabAtkins: First three issues are deeply inter-connected.
TabAtkins: Second one is keystone issue here.
<Florian> 1550 is not listed in the wiki, but also interconnected
[whiteboarding again]
[TabAtkins draws a table with columns flow/flow-root,
rows block/inline, and values
block / BFC / inline-block / inline (clockwise) ]
| flow | flow-root |
--------+--------+--------------+
block | block | BFC |
--------+--------+--------------+
inline | inline | inline-block |
--------+--------+--------------+
TabAtkins: Block has to inlinify to inline-block, and inline-block
has to blockify to block.
TabAtkins: To make this happen properly - we check if the value is
a special value.
TabAtkins: We could break the congruence between legacy values and
the two-keyword values so that we define that inline
blockifies to block and inline.
Scribe: fantasai (with nainar scribing fantasai speaking)
TabAtkins: Which would mean that inline-block won't behave the
same as inline flow-root
TabAtkins: even though they're the same thing.
TabAtkins: I have an alternate suggestion:
TabAtkins: It's still a little confusing, but maybe better
TabAtkins: That would avoid breaking existing implementations of
flow-root, which have already shipped.
TabAtkins: First suggestion is that we stick with block and inline
TabAtkins: But rather than just two values of flow/flow-root, we
have three, calling 1 2 and 3 atm
TabAtkins: in increasing order of BFCness.
TabAtkins: Legacy inline is inline+1
TabAtkins: legacy block is block+2
TabAtkins: inline-block is inline+2
TabAtkins: 2 is the "keep my children together" value
TabAtkins: 3 is the even stronger one, so flow-root is block+3
TabAtkins: and inline+3 is inline-super-block.
Florian: What is an inline-super-block?
Florian: In which cases do they behave differently?
TabAtkins: If it blockifies it blockifies to flow-root
fantasai: When does that matter?
TabAtkins: You contain floats and stuff
TabAtkins: So if you have a plain inline block.
Rossen: You have two inline blocks, and they are inside a flex.
They both get blockified.
Rossen: If those have floats inside, those floats don't affect
each other.
Florian, fantasai: Flex items are BFCs
Florian, fantasai: When does CSS blockify something and not turn
it into a BFC also?
TabAtkins: I can't think of any case...
Florian: What about the block+1 case?
TabAtkins: tiny-block
TabAtkins: tiny-block inlinifies to inline.
Florian: Concrete example?
TabAtkins: If you have a normal block inside of a ruby container.
If you put a tiny-block into a ruby then it turns into
a regular inline
TabAtkins: falls out of the 2x3 array.
TabAtkins: I guess then we have two values that fall out and
aren't really useful.
TabAtkins: So in that case, I think we should have a diamond.
Florian: So how's that different from 2x2?
TabAtkins: block and inline-block correspond.
TabAtkins: I guess flow-root doesn't inlinify? Or maybe becomes
inline-block?
[TabAtkins draws a bunch of arrows]
Florian: I don't know if this is useful.....
iank: Why can't we ?
TabAtkins: Because block has to inlinify to inline-block, and
inline-block blockify to block.
fremy: getComputedStyle, right
Florian: That and display: inherit, which nobody does.
Florian: Could we say that everything that BFCizes makes you go
from block to flow-root and independently from ...
Florian: Maybe?
TabAtkins: So given that block+1 doesn't have a use case, and
neither does inline+3 ...
fantasai: I think its silly to have a bunch of combinations that
are not useful - can't see how this is a better system
TabAtkins: I want inlinification and blockification to be simple
TabAtkins: 2x2 grid doesn't work, have to special case things.
fantasai: I think you're overemphasizing the importance of
inlinification being defined as swapping a keyword
in or out.
fantasai: If we take arrows this set of 4 values correspond like
that it will be better.
fantasai: We either have to syntactically disallow or have them do
nothing.
TabAtkins: ....
[TabAtkins redraws original 2x2 grid
TabAtkins draws arrows representing inlinification and
blockification]
TabAtkins: You don't have pairs, a flow-root inlinifies to an
inline-block which then blockifies to a block.
TabAtkins: But that doesn't seem to be a practical concern.
Florian: [Florian frantically pointing at the whiteboard yelling
"this"]
gregwhitworth: Can you please use words?
Florian: If the only difference between block and flow-root is
being a BFC
Florian: becoming a block ...?
TabAtkins: Inline block currently becomes a block when it
blockifies.
TabAtkins: It just happens to be an BFC in all these cases, but
its computed value is 'block'
TabAtkins: e.g. for flex items, if you specify 'display:
inline-block' and ask for its computed display you get
'block'.
TabAtkins: Generally the case, also for abspos etc.
TabAtkins: Because 'flow-root' didn't exist 15 years ago,
TabAtkins: I don't like it, but I'd be okay with just doing this
(points at 2x2).
TabAtkins: So it's fine.
TabAtkins: OK, so we can analyze the other things.
TabAtkins: So if we have blockification /inlinification algos just
explicitly map these values in the 2x2 grid.
TabAtkins: Then the next issue is ...
TabAtkins: This solves 1246
TabAtkins: where bz points out we get the wrong computed style
(get flow-root where breaks legacy).
Florian: I believe the board is a re-resolution of 1246.
TabAtkins: Also resolves 1496.
TabAtkins: Suggested resolution is that blockification of an
inline flow-root aka inline-block is defined to go to
'block'
TabAtkins: And inlinification of block flow special cases to
inline flow-root aka inline-block
fantasai: 1486 is still open?
astearns: So sticking with 1496
RESOLVED: Leave 'display' syntax as-is for #1496
RESOLVED: For 1246, inlinification of 'block flow' goes to inline
flow-root aka inline-block, blockfication of inline
flow-root & inline-block go to 'block'
RESOLVED: For 1486, issue is moot because 1246 resolution was
reverted (above)
fantasai: Inline flow-root what is the computed value if we aren't
blockifying?
fantasai: The serialization?
RESOLVED: 'inline flow-root' serializes in getComputedStyle as
'inline-block'
'flow' inner display type should never establish a BFC
------------------------------------------------------
GitHub: https://github.com/w3c/csswg-drafts/issues/1550
TabAtkins: This is oriol asking, mechanisms that turn BFCs, why
not make them all resolve to display: flow-root
instead. And we can't due to web-compat.
Florian: It's not that there are 2 behavior for flow, there are 4,
and flow is way overloaded.
TabAtkins: 2nd and 3rd are the same thing [missed some of list]
TabAtkins: Flow creates regular blocks and sometimes BFC
TabAtkins: That's just the way it is.
TabAtkins: oh, I see.
TabAtkins: Actual suggestion is to change the value at used value
time.
TabAtkins: That doesn't mean anything, because it's post box tree
construction.
TabAtkins: Used values are for turning box tree into fragment tree.
dbaron: No, used values are just how we describe transformations
that happen after inheritance
dbaron: i.e. anything that's post-computation.
fantasai: Isn't this editorial? He is saying that instead of
describing things as we have it - we should vocab and
change flow to flow-root for used value.
"This change should have no effect in practice."
TabAtkins: ...
TabAtkins: Computed value is everything before you inherit, and
used value is everything after inheritance.
Florian: No way to distinguish, but you could say that box tree is
computed off of used value of 'display'
Florian: introducing this concept as a way of explaining what
happens.
fremy: All the old specs we already have will be even more
confusing.
TabAtkins: We already have had to edit every spec
TabAtkins: e.g. "height behaves as auto" thing.
TabAtkins: Not actually every spec anyway.
TabAtkins: Seems okay.
TabAtkins: dbaron?
astearns: Given item wasn't on agenda, and this is first time
apparently anyone understood it...
TabAtkins: OK, can discuss later.
Florian: It was sort of on the agenda, next issue links to this
one.
astearns: OK, let's switch the topic and get minutes posted to the
correct issues.
Becoming a formatting context
-----------------------------
github: https://github.com/w3c/csswg-drafts/issues/1457
TabAtkins: Big issue is 'contain' property
TabAtkins: which requires element to establish a formatting
context.
TabAtkins: But it's not meaningful, can't just say it establishes
a formatting context out of the blue, e.g. an 'inline'
can't.
TabAtkins: Could say that it turns into an inline-block, though.
TabAtkins: But can't do that to Ruby.
TabAtkins: So what should we do here?
TabAtkins: Most cases it's a no-op, grid/table/etc is a no-op
TabAtkins: Block has an easy answer: switch to flow-root.
TabAtkins: Inline has an easy answer: switch to inline-block.
TabAtkins: Ruby is the only one that has a difficult issue.
Florian: In other cases, we haven't had a problem with this
Florian: e.g. 'overflow' doesn't apply to inline/ruby, so don't
have to worry about these cases.
Florian: Similarly column-span only applies to block-level
elements, so no problem there.
Florian: The only case where we have a problem is 'contain'
Florian: which needed to apply to 'inline' and 'ruby'.
Florian: So we need to establish terminology, and oriol's
suggestion works for this.
Florian: The alternative is to not add terminology for this, and
just say that these things blockify and [missed]
fantasai: Ruby can be block-level.
fantasai: Ruby spec defines block Ruby. You can't turn into a
inline block Ruby which is what you were trying to say.
Florian: Might be worth leaving existing places the way they are
Florian: and have 'contain' blockify, and the rest is obvious.
Florian: If there's an easy way to define this, then we should,
and then call into it from all these places.
Florian: Oriol's suggestion solves this case.
TabAtkins: So what should we do for ruby?
fantasai: Two solutions here. Third one is what you were trying to
do - ruby makes an inline block ruby thing. No use
case, so not a good idea.
fantasai: Second thing we could do - florian mentioned to blockify
ruby and the inline. That is inconsistent with inline
block. They get to stay as inline-blocks.
fantasai: Weird to have ruby turn into a block element.
fantasai: You could turn all inline level things into block level
things.
fantasai: Last thing, this aspect of contain doesn't apply to
inline/ruby - the author should change it into a block
first. Author then chooses to make the display
transformation.
TabAtkins: No reason not to apply contain to inline-block.
TabAtkins: You mentioned block ruby.
fantasai: Confirms that if you specify display block ruby you get
a block with ruby inside it.
fremy: Ruby does special alignment things.
Florian, fantasai: it's not different from inline
TabAtkins: Can we make block ruby a BFC?
TabAtkins: Only thing is that if you have a float, it won't
intrude the way it does for regular blocks.
Rossen: No reason to have inline layout of ruby be different from
regular inline layout.
fantasai: Why not go with the last option?
TabAtkins: ...
fantasai: To apply to neither inline/ruby - you the author must
turn it into an inline-block or block (depending on the
author's preference)
TabAtkins: Ok, I'm down with that.
dbaron: Issue is that contain is that authors won't know what
effects to get.
TabAtkins: Then it's a no-op, they're putting it there for trash
reasons.
fremy: They're not getting worse performance.
...
dbaron: Elements nested inside each other, and accidentally stuck
property on inline instead of the inline-block.
fremy: dom inspector can show that it doesn't apply.
astearns: What if they applied it to a box that was block, and
then changed it to an inline and now they lose the
performance benefits.
fantasai: Keep in mind that if you had a contain on there - when
you turned it into an inline you would not get the
layout you expected.
fantasai: If we didn't ignore it we would be forcing it into an
inline then.
fremy: Your question is like someone getting performance benefit
from ? and then turning it off and wondering why benefit is
gone...
astearns: I like the fact that 'contain' doesn't have the
blockification transformation with this.
TabAtkins: That would be a significant layout change, whereas for
other things its relatively minor.
Florian: After understanding it, you used oriol's terminology, so
regardless of whether we become an FC, I would support
adopting oriol's terminology,
Florian: It seems to me that we are getting closer to fantasai's
position, which is to not define the idea of becoming an
FC, and for all the situations except contain that may
have been ambiguous it was good enough
Florian: and for contain we will eliminate the problematic
situations so that it is also good enough.
TabAtkins: First resolution is for 1457, which is "what does it
mean to become a formatting context"
TabAtkins: resolution is that blocks become flow roots, inlines
and rubies can't establish a formatting context, and so
any property that tries to invoke this must exclude
them somehow.
TabAtkins: So we will change 'contain' accordingly.
astearns: dbaron?
dbaron: I think ppl often have a bunch of nested elements and the
display types are pretty random, and that usually just
work.
TabAtkins: Kinda, until people are like "why is there a 2px gap
below this thing?" and it's because they have an
inline-block instead of a block.
TabAtkins: You have to learn that.
Florian: Or fix it with margin-bottom: -2px :D
dbaron: If they have a baseline, won't have that problem though.
dbaron: Only if they fail to have a baseline.
astearns: So we could resolve on what Tab said, or resolve part of
it
<Loirooriol> Hi CSSWG, what about 'block ruby'? The block
container could establish a BFC.
<fantasai> astearns actually just asked that question to dbaron,
didn't get a chance to type it yet :)
<fantasai> 2nd question was also asked earlier, no answer yet
<TabAtkins> Loirooriol, It would be rather unfortunate if it was
impossible to have block-ruby flow around a float;
there's no reason to restrict that.
<Loirooriol> Tabatkins, I meant only when 'contain' needs a
formatting context
<TabAtkins> Loirooriol, then there's no way to create a block-ruby
FC without side-effects. :(
dbaron: I'm okay with resolving but kinda concerned about making
'contain' even more random
dbaron: I think one thing that is hard about web dev is that it's
hard to understand performance effects of things.
dbaron: Part of why contain is useful is it provides a way to make
them more predictable
dbaron: by forcing various types of isolation.
dbaron: If you make contain less reliable, then you're back to
unreliable.
fremy: I have a solution but no one will like it.
fremy: display: none
fremy: then author will find out it's a problem.
fantasai: We don't do dataloss by default.
Florian: Do we also need to stop confusing formatting contexts and
formatting contexts?
TabAtkins: Not directly relevant.
TabAtkins: Thinking to leave 'contain' issue undef for now
TabAtkins: or figure out something for ruby
TabAtkins: or say that contain doesn't apply to inline and ruby
TabAtkins: which do you like best?
dbaron: I guess I don't feel that strongly.
dbaron: I think you could say they become inline flow root or ...
fantasai: I think we imply anonymous containers for ruby
fantasai: I think if you turn display:ruby into just flow-root you
will get a flow-root ruby. Ruby does the same thing as
table.
fantasai: Set display:flow-root on a ruby element you will get a
block ruby BFC - all boxes needed for ruby will generate
correctly.
TabAtkins: You get a contained block and all the performance
benefits there.
fantasai: You have side effects like we turn off inlinification.
fantasai: You have block boxes inside a ruby container they
inlineify. They won't anymore.
fantasai: There will be some differences in behaviour...
fantasai: Actually it would break the case of not using rb elements
to wrap the bases,
fantasai: Because the base text's parent is no longer ruby
container
fantasai: The scooping algo would not scoop up ruby bases that
aren't in explicit elements.
fantasai: So nevermind, I guess that doesn't work.
TabAtkins: Then let's go ahead and do Loirooriol's thing of having
"used value of flow-root" terminology for all of our
BFCs.
astearns: Any resolution for becoming a formatting context?
TabAtkins: Not yet.
astearns: proposed resolution to take Oriol's proposal in 1550
TabAtkins: This is just an editorial change.
RESOLVED: Accept 1550
fantasai: Could say that the "becoming a formatting context"
section is css-contain's problem, remove it from
css-display
TabAtkins: yeah, since it's no longer affecting anything other
than contain
TabAtkins: so let's move to 'contain' spec, mark ruby and stuff as
open issues
RESOLVED: Move "becoming a formatting context" section back to
css-contain, mark ruby/inline as open issues to figure
out.
TabAtkins: Bunch of untriaged issues from Oriol, will talk about
them later.
CSS UI 4 and appearance
=======================
Scribe: TabAtkins (and fantasai for TabAtkins speaking)
github: https://github.com/w3c/csswg-drafts/issues/1250
Florian: There's an 'appearance' property. We started standardizing
it, because a lot of people use 'appearance: none' on form
controls to make them styleable in CSS.
Florian: This previously existed in prefixed form in most browsers.
Florian: Before standardization, the values other than none was a
very long list of all the ways an element could look;
this list was different across browsers.
Florian: We concluded this was impossible to standardize, in part
because many apply to pseudo-elements that other browsers
don't have, as they construct form elements differently.
Florian: Instead, we'd just have an "auto" value that makes form
controls look like whatever they need, and a "none" value
that suppresses it.
Florian: We could possibly extend this into a small list of
special values, like "button" to make it look like a
native button, but so far have resolved not to.
Florian: Now Mozilla said that they need to implement all of the
-webkit-appearance values.
Florian: I'm a little suspicious.
dbaron: Not sure if that's accurate.
dbaron: I think it's, *when* we implemented both appearance and
-webkit-appearance, sites broke.
Florian: They first said they aliased them to each other, and that
broke stuff.
Florian: That's expected, they're very different.
Florian: They said "we need to implement all the -webkit values
anyway, so the simple one isn't useful to us"
dbaron: Not sure that's what we said/meant.
Florian: Then I'm confused and need to know what they mean.
<tantek> FYI: https://bugzilla.mozilla.org/show_bug.cgi?id=1368555
<tantek> see the webcompat.com URLs in the above bugzilla bug
Florian: "fwiw, we intend to support -webkit-appearance with all
values that Chrome supports" ~ Mats Palmgren, June 7
<astearns> comment here:
https://github.com/w3c/csswg-drafts/issues/1250#issuecomment-306788821
dbaron: There are sites that specifically set "input { appearance:
none; } input[type=checkbox] { appearance: checkbox; }"
Florian: We did say that, if needed for webcompat, we could add a
handful of required values.
Florian: This is very different from adding all 50+ webkit values.
dbaron: If that's the case, then don't put 'appearance' in a spec
ready for impl.
dbaron: Otherwise people try to implement it.
TabAtkins: Maybe have a scary notice saying this is problematic.
Florian: I had that note. WG asked me to remove it.
TabAtkins: I'm fine with putting note back
TabAtkins: to say that we might need some values.
Florian: Cool. But that's different from saying we need all the
webkit values. Because then we need all the webkit
pseudo-elements, and I'm not speccing that..
jet: Doesn't mean we might not need it.
Florian: Maybe, but it'll be a huge effort. Need good proof it's
needed.
TabAtkins: So suggestion: add note saying don't implement this
property yet; it needs some subset of the
-webkit-appearance values; impls need to tell us which
subset is necessary.
Florian: Initial draft included the other values Edge supports for
-webkit; presumably that's for compat reasons.
Florian: WG told me to remove it.
gregwhitworth: My recollection was a question whether it was even
needed.
TabAtkins: David suggested we did - his example would break
checkbox rendering.
dbaron: I don't know the exact details, there's so many bugs and
compat stuff it'll take a while to untangle.
Florian: So two options: none | auto | <non-exhaustive-list> ; or
none | <exhaustive-list>
fremy: Alternately: let it take any keyword, treat unknown ones as
"auto".
Florian: That doesn't match today.
astearns: Why is "auto" only with non-exhaustive list?
TabAtkins: We could put it with exhaustive, and we could omit it
from the non-exhaustive list. Depends on details.
fremy: If you have "div { -webkit-appearance:button}", nothing
happens. But "input { -webkit-appearance: none; }" does
work; using "checkbox" will work on a checkbox input, but
won't turn a text input into a checkbox.
<fremy> TabAtkins, yes
<fremy> TabAtkins, input { -webkit-apperance:none}
input[type=button] { -webkit-appearance: checkbox }
renders as a button
ericwilligers: I heard dbaron say that if they ship appearance
it'll break compat. Can we just change the name?
Florian: And then we can avoid saying "none", and use "normal"
instead, which sounds better.
dino: Who implements unprefixed appearance?
Florian: Nobody that I know, but I last checked a while ago.
dbaron: We tried, but backed it out before it hit stable.
dbaron: It's not clear what portions of the problem were with
"appearance" and which were with "-webkit-appearance".
dino: I was considering implementing unprefixed with just "none"
and "auto".
tantek: One of the points Mats made is that this isn't a
particularly useful feature for web authors.
tantek: So one proposal is just to drop it entirely.
fantasai: People use it a lot.
TabAtkins: I use "none" plenty to do styles on my buttons, etc.
dbaron: It's not clear to me which of these was the good reason to
back the whole thing out.
dbaron: One of my guidelines is that if a user reports a bug,
that's a compat problem; if the dev does, that's not
necessarily a compat problem.
dbaron: And one of them was reported by a dev, because it comes
with a jsfiddle.
TabAtkins: That said, your example looks believable.
TabAtkins: It would be fixed by fremy's proposal.
astearns: Would also be fixed by minting an entirely new property.
astearns: So that seems like a cleaner solution.
TabAtkins: Possible conclusion, just leave this unresolved, but
note the handful of possible solutions and ask impls
to tell us which they want to do.
Florian: Seems better than trashing it.
RESOLVED: Put a note into "appearance" saying it's not ready to
implement, list the possible solutions discussed here,
ask impls which they want to do.
<tantek> seems like a lot of work for very little benefit
<tantek> so I question why
TabAtkins: Answer to tantek's question is that people use it for
useful things today
TabAtkins: and there is no other solution for what they want today.
<tantek> where is the documentation of the use-case in the spec?
let's drop a URL here for the minutes.
<tantek> how high does the cost have to go before it is obviously
not worth the supposed benefit?
Florian: Another warning for the spec: the high-level doesn't need
to change, but details are insufficient.
Florian: When you appearance:none something, the native-ness goes
away.
Florian: AND this does not affect its behavior; events still
happen, etc.
Florian: This is established.
Florian: What's not established is: if you "none" a button, does it
look like an unstyled div, or is there UA styles that make
it button-y, which you can replace.
Florian: Another thing: for a range input, you probably can remove
the graduation on the bar that tells you where you are,
but you can't remove the thumb; otherwise you have nothing
to drag.
Florian: So going from the high-level principles that you need to
keep it interactive, we need to dive into every control
and specify what disappears, what is done by the UA
stylesheet, and what is kept no matter what.
Florian: If you want me to spend time doing this, say so
explicitly.
dbaron: I think some impls can assume they always have a native
appearance.
dbaron: A number of platforms provide an API that says "draw a
background of a button".
dbaron: The original spec didn't say this, but I think both impls
of appearance were about replacing the border/background
of a button/widget with a native one.
dbaron: On some platforms you can rely on these native APIs always
being present and always working.
dbaron: On some you can't.
dbaron: Not sure if we care about those platforms, but we might.
dbaron: One thing that led us to retain our UA stylesheet is
because they always existed as fallback, for when the
platform couldn't draw a native thing.
dbaron: I think an example was older versions of windows not
having all the widgets, or Linux themes not always being
capable.
dbaron: At least GTK2, theme might be unable to draw if provided a
surface that wasn't a real GTK window, so you had to do
something else.
Florian: I think this is extra background for what I tried to
state earlier; a combination of principle and compat
requirements means that there must be *something* in the
UA stylesheet.
Florian: This research hasn't happened.
dbaron: And specifying border/background explicitly also turns off
appearance, on most (all?) things.
dbaron: And there are cases that "appearance:none" also turns off
*more* things.
dbaron: FF didn't do this, but WK eventually started doing this,
so there's lots of weird logic now.
dino: I don't think there's much we turn off with "none".
dino: Some cases where you'd get a native widget, but styles
change it to a non-native widget, so it changes appearance
dramatically...
dbaron: Some examples: the drop marker in a combo box...
dbaron: If you say appearance:none, the dropdown arrow next to a
<select> disappears; setting border/background doesn't do
this.
TabAtkins: Setting border/background doesn't kill the drop-down
TabAtkins: But setting 'appearance: none does'
Florian: And the spec is trying to require that behavior, because
right now it's unpredictable what will show up.
Florian: Because you don't know whether it'll be there or not, and
the pseudo-element varies per browser, when we style it
with CSS we need to specify what you actually get.
<dbaron> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cselect%20style%3D%22border%3A%20medium%20solid%20green%22%3E%0A%20%20%3Coption%3EOne%3C%2Foption%3E%0A%3C%2Fselect%3E%0A%3Cselect%20style%3D%22-moz-appearance%3Anone%3B-webkit-appearance%3Anone%22%3E%0A%20%20%3Coption%3EOne%3C%2Foption%3E%0A%3C%2Fselect%3E
<dbaron> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cselect%3E%0A%20%20%3Coption%3EOne%3C%2Foption%3E%0A%3C%2Fselect%3E%0A%3Cselect%20style%3D%22border%3A%20medium%20solid%20transparent%22%3E%0A%20%20%3Coption%3EOne%3C%2Foption%3E%0A%3C%2Fselect%3E%0A%3Cselect%20style%3D%22-moz-appearance%3Anone%3B-webkit-appearance%3Anone%22%3E%0A%20%20%3Coption%3EOne%3C%2Foption%3E%0A%3C%2Fselect%3E
astearns: This is all interesting, but I"m not sure we need to go
further into the weeds right now.
Florian: Yes, I'm planning on putting in a warning for this.
CSS Fonts 4
===========
Which font properties should be reset by the font shorthand?
------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1636
myles: Thanks to David, we now have a bunch of correct data.
myles: [presents it]
myles: I think there's some consensus that 'font' can reset
properties that it can't set.
TabAtkins: It has some "reset-only sub-properties".
myles: [explains table]
dbaron: Further question: what's a subproperty of font-variant?
myles: So should we look for that data too?
myles: So does anyone outside of dbaron have opinions on this?
TabAtkins: I think font-synthesis shouldn't be reset, everything
else I don't care, probably be reset.
dbaron: My pref is for 'font' to reset the font you specified,
and not leave a bunch of stuff unresolved.
fantasai: I strongly agree with Firefox's grouping, except unsure
about font-kerning.
myles: optical-sizing should be reset.
fantasai: Don't know what optical-sizing is, but agree with
resetting all of those as well.
dbaron: I think it's important that variation-settings and
feature-setting get reset.
[general agreement]
astearns: Why not font-synthesis?
TabAtkins: It seems like it's rarely tied to the precise font;
usually if you care, you'll make sure all your fonts
have it.
myles: Same probably applies to font-presentation.
[general agreement]
[general agreement that all the others should be; we went thru
several specific examples]
Florian: I'm not sure about font-variant
myles: That's *set* by the 'font' shorthand, it *must* be reset.
RESOLVED: All font-* properties are reset by the font shorthand,
except font-presentation and font-synthesis.
* fantasai still thinks font-presentation is a really confusing
name
<fantasai> How about font-iconography?
<bdc> (agree with fantasai, it's super generic -- just like
appearance btw)
CSS Counter Styles
==================
tantek: Yesterday we talked about language of counter-styles when
read out; we had weak consensus but no strong reasoning.
tantek: Since then, tab explained to me his reasoning for it being
defined by the UA language.
tantek: So we should revisit.
dbaron: I really don't like making things a function of the UA, as
that makes a webpage testing problem that most devs are
totally aware of.
dbaron: Easy to make things that work fine with an English
browser, and are strange with a Chinese browser.
dbaron: Encoding is an example.
TabAtkins: I agree with dbaron in general, but don't believe this
falls into that bucket of problems.
TabAtkins: This is about how to read numeric counter styles
TabAtkins: when you're in a screen reader UA need to read out in
numeric numbers.
fantasai: I don't think that's what it's about.
fantasai: If you're reading a French webpage in an English UA,
using alphabetic numbering, the UA will read it as "A B
C" (english)
fantasai: Weird to suddenly swap; the rest of the text is
referring to option A in French.
TabAtkins: Screen readers are relying on numbers to navigate the
page, need to have it in their UI language.
TabAtkins: Mismatch of the text referring to "option ah" and list
reading out as "list item ay" shouldn't matter because
the reader understands both languages.
Florian: I think I can turn your argument on its head.
Florian: If you're reading a webpage in French, it's unlikely
that, if it's in French, it would be usable with the
bullets in English.
Florian: So having a page of nonsense with a sensible list bullet
in the middle of it is not useful.
fantasai: If you're running a screenreader UA, and you always want
the numeric value of a list, it should have such an
option to use numeric values regardless of bullet style.
fantasai: It's a navigation interface at that point; different
thing.
TabAtkins: Relying on page language then is okay, but using
element's language is not good.
TabAtkins: Mostly English page with some Spanish text, switches
numbering, not good.
fantasai: So this isn't a question for a11y, but i18n. Maybe a bit
of both.
fantasai: But mostly i18n people.
astearns: I have an opinion, but I don't think it's worth as much
as polling people who use screenreaders with multiple
languages.
fremy: In an English comp, page is in French, even if your
screenreader can read French, it'll read a button with
French Text like "<french text> disabled" - speaking
"disabled" in English.
fremy: So I'm used to switching; it would be weird if it said
"disabled" in French.
TabAtkins: That matches with the "lang of the UA", not page or
element.
fantasai: Here is the problem I don't want us to have
fantasai: You have an ebook in French, and your reader is reading
the ebook
fantasai: It reads out "Chapitre twenty-three, François va à
Seattle"
fantasai: rather than "Chapitre vingt-trois, François va à Seattle"
fantasai: because you used CSS counters and GC to generate the
chapter numbers
fantasai: Instead of inlining them into the document source.
TabAtkins: That's a good example.
TabAtkins: It seems that goes back to your earlier example of
navigation being important to read in the UA language.
TabAtkins: I'm okay with saying that counter styles are read out
in the element language
TabAtkins: but adding a note that when reading out numbers as a
navigation aid, that's part of the UA interface.
astearns: And both of these things should be read by i18n and a11y.
fantasai: Right. We'll edit it together, I'll edit Text to have
the right hook and make sure it's published, and then
we'll ask for review once we have the prose.
<fantasai> I think it has the right hook at the moment, just
hasn't been published in a really long time so we
can't link to it from counter-styles :)
astearns: This isn't a requirement for the browser, but for the
screenreader.
TabAtkins: Right, the browser isn't using it as a navigation aid.
Florian: Might want an exception for lists - don't want "famous
authors: one, Steven King; ni, Murakami, ...". Should
maybe take language from the list instead.
fantasai: That's bad markup - the list item itself is English in
this context. If you're marking any Japanese, it should
be in a span around the name only.
fantasai: So that just needs more accurate markup; it's not for us
to fix.
RESOLVED: same resolution as yesterday
Received on Tuesday, 29 August 2017 21:56:45 UTC