- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 3 Jul 2014 11:42:48 -0400
- To: www-style@w3.org
Re-Chartering Reminder
----------------------
- Working group members were reminded to rejoin under the new
charter.
CSS3 Text Issues
----------------
- The mailing list proposal to change control characters to
default display in order to expose these breaks in pages was
discussed.
- It was clarified that this proposal would only apply to Unicode
characters that aren't default ignorable or CSS whitespace.
- There was general support for the change with most browsers
expressing support or no opinion. Microsoft requested more
time, so the intention is to change to default display control
characters pending Microsoft's input.
Flexbox Issues
--------------
- Tab informed the group that the thinking at the last F2F that
addressing the static position of an abspos child would be
the same if referencing a box or a point turned out not to be
correct when using safe alignment.
- A decision isn't made as to which behavior is better, so
for now this is purely informational.
- Tab also requested help in trying to discover how much usage
there is of flex-basis: auto with a non-auto value for width
in order to determine how much breakage renaming flex-basis:
auto would create.
- RESOLVED: Accept the change to main-size pending usage data and
future bikeshedding
Selector Parsing
----------------
- RESOLVED: Remove the Unicode range token from syntax and replace
with a Unicode production similar to <An+B>. Update CSS
Syntax, CSS Fonts, and CSS Font Loading accordingly.
min/max font-size
-------------------
- RESOLVED: Add min and max font-size properties
- RESOLVED: New ED for Fonts 4
display: contents
-----------------
- RESOLVED: Move contents to the display property
===== FULL MINUTES BELOW ======
Present:
Glenn Adams
Rossen Atanassov
Tab Atkins
David Baron
Adenilson Cavalcanti
Dave Cramer
Alex Critchfield
Elika Etemad
Daniel Glazman
Koji Ishii
Dael Jackson
Brian Kardell
Peter Linss
Michael Miller
Shinyu Murakami
Edward O'Connor
Matt Rakow
Simon Sapin
Alan Stearns
Lea Verou
Regrets:
Bert Bos
Philippe Le Hégaret
Anton Prowse
Florian Rivoal
Dirk Schulze
Greg Whitworth
Scribe: dael
Re-Chartering Reminder
----------------------
glazou: Let's start
glazou: First thing, before the extra items, I sent a message
about the re-chartering.
glazou: I reminded you that both individual members and invited
experts must rejoin.
glazou: You have 45 days or else you're removed automatically.
glazou: Any extra items to discuss?
<TabAtkins> Sorry, I was muted a second ago. Agenda+ for max/min-
font-size?
CSS3 Text Issues
----------------
<glazou> http://lists.w3.org/Archives/Public/www-style/2014Jun/0439.html
glazou: I think there's a message that fantasai sent to the list
from Jonathan Kew
fantasai: Basically we have an issue on if we should display
control characters. Currently browsers don't and this
message argues we should to expose broken pages and get
them fixed.
fantasai: koji and I don't have a strong opinion so we want the
working group's opinions. If we make the change it will
require a change to all implementations.
<leaverou> Isn’t this something that should be defined in the host
language?
<fantasai> leaverou, no, not really. If the host language wants
them to go away, it should pre-process them away. CSS
is what says how text is displayed.
glenn: Is this proposed as a style property?
fantasai: We're not proposing it as a style property. We don't see
a use case for control, this is about the default
behavior.
glenn: I would suggest a default of presenting control characters
is wrong. I think the author could choose to display them.
TabAtkins: The point of the thread was authors don't want them to
display, they do it accidentally. You never want
control characters to display. There's silent data
corruption because they're left accidentally.
TabAtkins: If the default stays as don't display, it doesn't solve
the request and having an author able to choose if it
displays doesn't help either.
glenn: For example in Unicode there's many control characters...
fantasai: No.
TabAtkins: We're talking about the block of 32 after ascii.
fantasai: Default-ignorable characters are not affected.
glenn: C1 controls only.
glenn: So there's no semantic controls assigned to those?
TabAtkins: Certainly not on the web.
TabAtkins: If they were having, them stay invisible isn't great.
glenn: So I wouldn't object to the C1 characters but it seems a
special case.
TabAtkins: It is because all the others are marked by Unicode to
ignore. These aren't so at the moment by ignoring them
we're somewhat violating Unicode.
TabAtkins: Since other parts of the tech stack don't ignore them,
but browsers do we should help authors realize there
was a mistake.
* fantasai wants to hear from browser vendors
* leaverou wonders how many websites would start looking broken if
this change goes through.
glazou: Is there anything else to say about this? I'm a bit lost.
<koji> I believe his proposal includes C0 too.
glenn: [reads koji comment]
fantasai: It includes all the characters that aren't default to
ignore or CSS whitespace.
glenn: Is there a default display for C1 control characters?
fantasai: No, but I think that we would say they must render some
kind of glyph, be that a missing character glyph or the
corresponding symbol or what...
TabAtkins: As an example m-box right now renders C0 as their tiny
name in a diagonal row across an m-box.
TabAtkins: Might be a special font. Browsers can have default
fonts that render or they get a last resort character.
fantasai: Basically render and be treated as visible for render
and line breaking.
<SimonSapin> TabAtkins, Wikipedia uses these separate code points:
http://www.fileformat.info/info/Unicode/block/control_pictures/list.htm
fantasai: Key thing is do we display control characters or
continue to ignore them? I'd like to hear from browsers.
glenn: I think we should hear from Unicode or i18n.
fantasai: Unicode says display.
koji: I talked to Unicode list and they said we should display in
identities like URL and says the effects shouldn't apply to
CSS rendering.
<koji> http://Unicode.org/pipermail/Unicode/2014-July/000801.html
fantasai: We're a higher level protocol so we can do what we think
is appropriate.
glenn: But if what we think is appropriate is the opposite of what
they thing, it's worth considering.
fantasai: Any opinions from browser vendors? Do they need more
time? Not care?
TabAtkins: As much as I represent a browser vendor, which is only
slightly, I'm fine with the change.
fantasai: Do you want them to display?
TabAtkins: I'd rather have them display. Or be default ignorable
so they're ignored by everything. This halfway is no
good.
fantasai: Microsoft?
Rossen_: I have to check with the font guy.
fantasai: Opinions for Apple or Mozilla? Opinions, more time?
dbaron: Jonathan works for us so I think that's a clear opinion.
There might be others who disagree with him.
fantasai: But not you.
dbaron: I don't have a strong opinion, but tend to agree as long
as it works.
fantasai: Anything from Apple or Opera?
[silence]
glazou: Apparently not.
koji: On the Unicode mailing list, opinion was that the spec said
everything except default ignorable should be displayed
visible.
koji: So if we go and display the discussion might not stop there
and we'd need more.
TabAtkins: What else?
<koji> http://www.Unicode.org/Public/UNIDATA/DerivedCoreProperties.txt
koji: Unicode says display everything that isn't default ignore.
If you look at the above url you have the list of default
ignorable
<fantasai> http://www.fileformat.info/info/Unicode/category/index.htm
koji: So characters with glyphs assigned, there'd be plenty to
display.
TabAtkins: I think we display those in chrome.
TabAtkins: We do unknown glyphs. Same for FFF. Sometimes there's a
glyph in the corner.
glazou: Unless there's more to discuss, I'd like to move on.
fantasai: My take-away is we'll change it to say control
characters are displayed unless Microsoft says otherwise.
Is that correct?
<fantasai> Since Apple and Opera have no opinion and Mozilla is
strongly in favor.
group: Yes.
Flexbox Issues
--------------
glazou: There's 3 in the agenda
TabAtkins: First item, in the last F2F we thought that phrasing
abspos text with the position as a point vs as a box
are equivalent but they're not due to safe positioning.
TabAtkins: If safe is on there's a difference between where it
displays with the old text and the current text using
points to align.
TabAtkins: In the old text if the box was really big it would
shift to the side, but now it stays truly centered.
TabAtkins: This might not be a problem, we're not sure. We're
bringing up that there is a difference we didn't know
about before. We plan to review the abspos text in
general and make it better, so we may review the change
then.
TabAtkins: We're just brining up that some change may be needed
and therefore may need approval.
dbaron: So which way is the text and what's the planned change?
TabAtkins: We positioned the child as it's the sole item in the
flex and that gave us a box to position in. The new
text was that the static position should be a point and
rephrase in terms of finding a point and aligning the
abspos to that.
TabAtkins: Because the old text honored safe align and the new
text doesn't, we're not sure which way is best to
handle and which we want to end up with in order to
make sure it's specified clearly.
TabAtkins: Right now the only definition is unclear about exactly
what the static position is.
Rossen_: So you're suggesting we need to clear up what the static
position means?
TabAtkins: I think we'll need to do that unless fantasai included
a simpler approach. It's a 'hey we'll need to revisit
this as we narrow things down' statement.
TabAtkins: Next issue.
<fantasai> This is the issue :
http://lists.w3.org/Archives/Public/www-style/2014Jul/0008.html
TabAtkins: This needs discussion. We discussed that flex-basis:
auto is odd because it overlaps with width so you have
to say flex-basis: auto and width: auto.
TabAtkins: It's also weird that computed and used values of auto
mean something different.
TabAtkins: We discussed re-naming flex-basis: auto. We
provisionally are using main-size
TabAtkins: We're leaving the short hand as is because it's used
too widely.
TabAtkins: So is the name change okay and does anyone have the
ability to track what the actual usage of flex-basis:
auto is and if it's paired with non-auto width?
TabAtkins: Right now chrome is showing a disturbingly high number
of uses. I think a lot of tutorials ignored our note
not to use. Hopefully there isn't much paired with non-
auto width because that's the real problem.
TabAtkins: If anyone has a way to track this, that would be
awesome and, if not, we might just make the change and
see how much breakage there is.
TabAtkins: Any thoughts or suggestions on a better name than
main-size
<dbaron> I'm happy with the change assuming it sticks.
Rossen_: This is in the current ED?
fantasai: Yeah.
Rossen_: I was looking at it and...
TabAtkins: Do you see it now?
Rossen_: Yeah.
Rossen_: That sounds pretty good.
TabAtkins: Okay.
TabAtkins: If there's no objections for now we can stick with it
and if someone comes up with a better idea, post to the
ML thread.
Rossen_: So, to clarify, you see a bunch of flex-basis usage, but
can't track values?
Rossen_: I'll see if I can run a query.
TabAtkins: If you can, check to see if you can find flex-basis:
auto paired with a non-auto width
TabAtkins: It would be good to know how much flex-basis: auto
there is, but we also what to know how much will change
when we say it's actually auto, not to look at width.
Rossen_: Is this a change fairly soon?
TabAtkins: We just changed the spec yesterday. There's no
implementations yet.
fantasai: The other name option was match-size.
TabAtkins: I didn't like it because it seemed to imply that it
should look at another element, but it's not a strong
objection.
Rossen_: I think main-size is good. I'm sure there will be a lot
of action once we get close to another round of calls.
Then we'll get 10 other names.
fantasai: Seems people are happy with the general content.
Rossen_: Yes.
fantasai: So resolve accepting the change pending usage data and
future bikeshedding?
glazou: Any objections?
RESOLVED: Accept the change pending usage data and future
bikeshedding
glazou: Next one?
TabAtkins: Next is fantasai or dbaron?
Rossen_: There's another flex?
TabAtkins: No, there were just 3 links, but 2 topics.
How far from bases should ruby text be?
---------------------------------------
fantasai: dbaron do you want to do this on the mailing list?
dbaron: Yeah, let's discuss on the list.
glazou: gregwhitworth sent item 4, but sent regrets, so I think we
should move to item 5 for now.
Selector Parsing
----------------
<glazou> http://lists.w3.org/Archives/Public/www-style/2014Jun/0486.html
TabAtkins: The issue is that the Unicode range token we just
discovered has a long running source of potential bugs.
<TabAtkins> div u+a { color: red; }
TabAtkins: Okay, pretend that was a real color.
TabAtkins: This is looking like div with a decedent and a sibling.
This parses as a div ident,
TabAtkins: And then a white space,
TabAtkins: Then a Unicode range token with the value a.
TabAtkins: This happens any time you have an underline tag
selector followed by a sibling combinator followed by a
through f.
TabAtkins: So the selector will be invalid accidentally.
glazou: So does that mean current browsers fail?
TabAtkins: Chrome and Firefox at least call that invalid, IE does
not. Selector parsing is defined loosely. At least 2
browsers consider it invalid.
TabAtkins: This is with CSS minifiers that removes space around
combinators except in this one case.
TabAtkins: The suggestion is to fix this by killing the Unicode
range and instead use something like <An+B>.
TabAtkins: It'll be just as ugly and complex, but we know it's
possible and you can't put one together that works.
TabAtkins: I think this is the right way because it's an odd
parsing case that doesn't look like anything else in CSS
<SimonSapin> +1
<fantasai> I am strongly in favor of doing this.
<fantasai> Unicode-range is only used in one place in the entire
language; shouldn't be causing problems anywhere else.
TabAtkins: I can see how special purpose tokens can cause problems
here or in the future.
TabAtkins: So I say we replace with a production and make sure the
two specs that care, font and font-loading, get updated
appropriately.
fantasai: I think this is a good idea.
TabAtkins: Some people on thread seem okay with it, but I want to
hear objections.
<leaverou> +1 for the change
glenn: Do you have a concrete proposal for replacement syntax? You
said something like <An+B>, I was wondering if you have
actual proposal.
TabAtkins: I have it in my head, but not in the spec. If I have
difficulties I can bring it back to the list.
fantasai: We have people in favor. Anyone not?
<bkardell_> +1
<glenn> +0
glazou: I'm in favor.
dbaron: It seems like a bunch of work to implement so we may not
do it immediately and may do a patch and later do it the
right way. It's easy to fix doing context-dependent.
TabAtkins: It's easy with implementations, but I'm for solving it.
dbaron: Context-dependent tokenization is worth avoiding in the
long run.
RESOLVED: Remove the Unicode range token from syntax and replace
with a Unicode production similar to <An+B>. Update CSS
Syntax, CSS Fonts, and CSS Font Loading accordingly.
glazou: That was shorter than expected. Rossen_ can you do
gregwhitworth's item?
Rossen_: I think TabAtkins was saying he has something to say.
TabAtkins: I have an agenda+
Rossen_: So let's do that and if we still have time I'll talk.
* fantasai also has agenda+ for display: contents
max/min font-size
------------------
TabAtkins: I think this is a reasonable request, such as when I'm
doing a large text and want it bigger but not bigger
than the screen. It should be sized in viewport units,
but not larger than the viewport.
TabAtkins: It seems reasonable, but I'm wondering if there's issue.
TabAtkins: There's a min and max property and you resolve in the
same way max and min are done. If it violates max,
resolve and if it violates min resolve again.
TabAtkins: So in my case if you want really big text, but not have
overflow.
<leaverou> {min,max}-font-size have been requested quite a lot by
authors.
<tantek> copyfitting!
fantasai: I think this is reasonable to have. The only alternative
is if we introduce max and min functions so you can put
it inline.
fantasai: I agree with solving with either the property or the
max/min functions.
TabAtkins: They're not incompatible. We could always add the
second later.
dauwhe: Is there an accessibility concern?
TabAtkins: I think the opposite. Min font size can be useful so
that whatever fancy units you use, you don't get
smaller than 15 px.
dauwhe: It sounds like this could help the ebook world.
TabAtkins: So are there any objections or any reasons why we
haven't adopted this besides the possible duplication?
<hober> max-font-size: 80vh; min-font-size: 12pt;
MaRakow : I'd be interested in seeing how we're supposed to use it.
So min size is so it stays readable, but you're
resolving on max?
TabAtkins: Min wins all conflicts. That matches existing
implementation.
MaRakow : If you're doing the example from hober, 12 would be
favored?
fantasai: You use the font-size property to set the font size and
this places a limit.
MaRakow : So you use all three in combination?
fantasai: Yes. You set min max on the document and use font-size
to set the font size throughout the document, knowing
that and know that when you set the font it will never
go above or below your min/max.
TabAtkins: Keeping the same semantics as min/max width seems
sensible. Max prevents overflow and min prevents
unreasonable smallness so, for accessibility, honoring
min when it conflicts max is sensible.
<tantek> do we have font-size:auto yet?
TabAtkins: fantasai, do you object to the property, or want to
give another try to functions?
fantasai: No, it makes sense. You may want to do things
separately, so separation gives better usability
TabAtkins: Cool.
TabAtkins: So any objections?
RESOLVED: Add min and max font-size properties
<tantek> nice - well done all
TabAtkins: Is John still fonts editor?
glazou: He asked to leave the working group temporarily.
TabAtkins: Then I can do editing.
fantasai: Fonts is in CR so do we add to 3 or 4?
fantasai: I think the syntax should be level 3, but this is a new
feature. Maybe toss it in an ED?
??: Elsewise we'd have to go back to LC?
TabAtkins: Yes, until we remove LC as a level.
TabAtkins: So I will add the properties to an ED that I will start
and whenever we made the edits, we'll make sure they
happen on the Fonts 3 CR. If we do this right, it'll be
an informative change.
glazou: So if there's a new ED, we need a resolution. Any
objection to starting a new ED for Fonts 4?
RESOLVED: New ED for Fonts 4
<tantek> new ED, implementations, test cases, interop, slip it
into a Fonts CR iteration
* fantasai thinks she agrees with tantek in this particular case,
it's a slight enough addition
glazou: I guess that closes this issue. Anything in the last 9
minutes?
display: contents
-----------------
<fantasai> mail describing the issue:
http://lists.w3.org/Archives/Public/www-style/2014Jul/0023.html
fantasai: TabAtkins and I were discussing this and TabAtkins
brought up we have display-box that takes none, normal,
and content. The purpose of splitting was to create a
dedicated switch for turning visibility on/off.
fantasai: This violates that goal. So it's the same problem as
with the display. So the proposal is to move content out
of display-box so that it's just about hiding or showing
since that needs to be a separate switch.
fantasai: Especially since contents is separate of display type.
TabAtkins: None also belongs, but there's reasons to leave it. So
this is so we can have an item hidden and can easily
toggle without having to know everything about it.
TabAtkins: We think it would be okay so that whatever property is
holding display: none can have multiple items hidden.
Right now we have display: none that prevents from
displaying, and another where it hides, but makes it
create them for the purpose of counters and the like.
TabAtkins: We think we can do multiple hiding properties and one
shown and still get away with the use case.
fantasai: I think you don't want multiple for hiding, but for this
discussion, this is just moving contents into the
display property.
TabAtkins: Display is a ED until I finish the edits I was supposed
to make in January. Since we're going to publish a WD
it should be approved
<fantasai> TabAtkins, display module is already fpwd
<fantasai> www.w3.org/TR/css-display-3/
glazou: I don't want you to perceive and receive this as a flame,
but I have a feeling this goes far beyond what web authors
will understand.
glazou: I'm not saying we don't need the feature, I think we are
reaching levels of complexity in our solutions that are
beyond the users ability.
glazou: I think we need to think more and find something more
usable and readable.
dbaron: About what?
glazou: All the display-* properties
fantasai: This is taking a value out of a property that's
basically show or don't show the box. That's a clear
switch that authors want and it needs to be separate
from the box display type.
fantasai: We're asking to put it back into the display property.
Rossen_: When you say show/don't show, you mean affect or don't
affect the layout?
TabAtkins: This is the display: none value pushed into a separate
property.
Rossen_: But it still computes those things inside?
TabAtkins: The normal is no behavior change. We think we can add a
value that does compute inside and just doesn't display.
Rossen_: It's pretty hacky.
fantasai: That's not what we're discussing now. The issue is we
have a property in a WD that takes these three values.
It's show or don't show the box, but it has a value
that's a display type. That should be in the display
property. We want to move it from the 'show/don't show
the box' property to the 'this is how we display'
property
fantasai: I just want a resolution on that. We can discuss the
rest later.
TabAtkins: So does anyone object to moving the contents value?
TabAtkins: Sounds like not .
Rossen_: It's probably okay. I'm sure we'll revisit.
fantasai: Anyone else?
fantasai: You all just really don't care?
Rossen_: It's time so people want to go away.
TabAtkins: It's a time-out.
fantasai: So do we resolve?
glazou: No objections?
Rossen_: Doesn't sound like there's support or objection.
glazou: Yes.
Rossen_: I don't see why we'd block keep on working. It sounds
like they're still going on that spec and we'll be
discussing it again.
glazou: That's a suggestion to defer?
fantasai: I'd like a resolution that content goes on display or
display-box. We have it in the WD and people are
apparently implementing this, according to the last F2F
discussion, so does this go to display or display
none-ness?
SimonSapin: The proposal sounds good. To move it to display
property.
glazou: Objections?
glazou: Support? Comments? Everyone can live with it?
Rossen_: For the time being.
RESOLVED: Move contents to the display property
glazou: So this is the end of the call. Thank you and bye
everyone!
Received on Thursday, 3 July 2014 15:43:16 UTC