- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 23 Apr 2015 11:35:51 -0400
- To: www-style@w3.org
Pre-wrap and White Space Processing Followup
--------------------------------------------
- Everyone was encouraged to read the email from Florian outlining
the different implementations and possible solutions.
- Discussion will continue on the mailing list and this will
possibly become a F2F topic in May.
Which spec for column-span: <integer>
--------------------------------------
- RESOLVED: New ED for the next level of multi-col
- RESOLVED: Add just Florian as editor for the time being
Media Queries
-------------
- The grammar for <media-condition> will be changed to avoid
requiring looking ahead by an unbounded amount.
- TabAtkins and Florian came up with the right behavior set for
@media not (unsupported-media-feature) vs @media not
(unsupported+syntax), but it's different from previous
proposals, so they'll contribute their new idea to the mailing
list for further discussion/objections before hopefully
getting resolution next week.
- TabAtkins and Florian came up with a proposal to address custom
MQ before an @import and will write the proposal for the
mailing list.
Font MIME Types
---------------
- RESOLVED: Font MIME type registration is out-of-scope for CSSWG,
FontsWG has a (partial) list, forwarding issue to them
Allow Extended Hebrew Counters
------------------------------
- RESOLVED: Add that people may support larger Hebrew counters if
they want
- RESOLVED: Re-publish Counter Styles CR with the above addition
Ruby inlinize algorithm
-----------------------
- The spec authors need more time to consider this question.
Addition of a ::flex-line pseudo-element
----------------------------------------
- This addition might be good for a future level of flexbox, but
not for the current level.
Naming issue for cursor: default
--------------------------------
- Consensus was that renaming the global default was the least-bad
option and the name bikeshedding will happen on the mailing
list.
===== FULL MINUTES BELOW ======
Present:
Tab Atkins
David Baron
Bert Bos
Bo Campbell
Dave Cramer
Tantek Çelik
Elika Etemad
Simon Fraser
Daniel Glazman
Tony Graham
Dael Jackson
Brad Kemper
Chris Lilley
Edward O'Connor
Simon Pieters
Anton Prowse
Florian Rivoal
Andrey Rybka
Simon Sapin
Alan Stearns
Johannes Wilm
Steve Zilles
Regrets:
Rossen Atanassov
Sanja Bonic
Adenilson Cavalcanti
Alex Critchfield
Peter Linss
Michael Miller
Takayuki Tsukitani
Ian Vollick
Greg Whitworth
Scribe: dael
glazou: Let's start.
glazou: First thing, anything to add to the agenda?
Florian: I was saying I have a few more things, but since the
agenda is full I can ping you to add them next week.
glazou: If you want to be sure they're added, drop an e-mail to
plinss and myself.
zcorpan: Starting next week I will be away until mid-Aug.
Pre-wrap and White Space Processing Followup
============================================
<Florian> https://lists.w3.org/Archives/Public/www-style/2015Mar/0386.html
Florian: Here's the e-mail. We discussed this a while back, but I
had one problem because some of what I had was only
partly accurate.
Florian: Starting again, we have an interop problem with
white-space:pre-wrap. There are three behaviors out there
and IE, Webkit/Blink, and Firefox all disagree.
Florian: In some cases IE disagrees with itself and does different
things in textarea vs regular elements.
Florian: Overall if you combine the properties you can't really
control how things work. I think that's unfortunate. The
mail explored who does what. I think there are a few
useful behaviors using these properties. It would be nice
to be able to switch between those properties, but right
now you can't do that with switching. We should aim for
more interop.
Florian: I'm not sure we can discuss on the phone call because I
think we need to look at drawings. I'd like to encourage
people to look on the ML and we can have a discussion
here on the high level on if interop is a desirable thing.
<fantasai> +1 to f2f
<andrey-bloomberg> +1 for f2f
glazou: It can serve as a reminder for everyone to look at the
e-mail and have it at the F2F.
tantek: Is this errata?
fantasai: CSS3 Text errata and new properties
Florian: I'm not sure it needs new properties. We can probably get
there with existing properties to describe it, but there's
currently a lot of ambiguity. There's also spec
violations. If you combine undefined behavior, ambiguous
spec prose, and spec violations you get all
these behaviors.
Florian: Last time there was feedback from MS and Apple saying
they didn't want to change, but given that there is no
interop I'm not happy with that. I'd like to hear from
the rest of the group on if they want progress.
<andrey-bloomberg> +1 for interop as well
fantasai: I'm happy to work on it but if implementors don't want
it they'll ignore it.
Florian: I'm a bit uncomfortable with not wanting to change
something that isn't interop. But if browser vendors
don't want to change that's tricky.
fantasai: Given that everyone is silent, we can work on it and
people can object.
<Bert> (Very good e-mail by florian, by still best to use a white
board, I think... I don't like spaces that collapse to zero-
width, b.t.w.)
<dbaron> I think interop is useful; these issues don't seem like
the top priority for authors, but making simple changes
seems like it could be valuable.
* ChrisL would like to know why the browsers are not interested in
interop here
Florian: So look on my mail, I think I've worked out what everyone
does, and I've proposed alternatives on what we can do.
I'd like feedback. I can do it on ML or bore everyone at
the F2F.
fantasai: I don't have time until then anyway.
glazou: So we'll revisit when there's more input or the F2F.
Which spec for column-span: <integer>
=====================================
<glazou> https://lists.w3.org/Archives/Public/www-style/2015Mar/0496.html
fantasai: Do we have any implementors? Others than Presto?
<ChrisL> do we have any *maintained* implementations?
Florian: This seems useful to me. Does Bloomberg have an impl of
this?
andrey-bloomberg: I don't remember. Let me check.
fantasai: I think it's great that Presto implements this, but we
dropped it from multi-col and it ended in GCPM. If
there's no interest in impl we should drop.
<Bert> Prince applies column-span: number to floats, I think.
Florian: Bloomberg has an implementation. It was in a spec, but
dropped because the spec was re-purposed. It's
unfortunate to drop when there's two impl, even if
they're minor implementations.
johanneswilm: This was in page floats. The only reason it was
removed is there were many different definitions and
this seemed unrelated to page floats.
johanneswilm: So the discussion was if it should be in its own
spec or if it should sit somewhere.
Florian: I can start a multi-col level 4 while we wait for other
things.
fantasai: The logical place is multi-col. If this was minor
feature impl by a few minor things...it's great to
document but layout features take a lot of work. If
there's interest in impl this going forward we should
have this.
Florian: Bloomberg has this and would like to contribute, but
that's hard without a spec
<andrey-bloomberg> just to clarify Bloomberg commits are going to
chromium and hopefully upstream
fantasai: This goes in multi-col, but that needs a lot of work and
so you're volunteering to take on a layout spec.
Florian: I'm not volunteering to take on the whole spec. I can
create a new level until someone is ready to take it on.
I'd be fine with it going at the bottom of page floats.
fantasai: If you want progress it needs to be in a multi-col spec
and work on the interactions. If you want a place to
copy it, there's a copy on TR. If no one is going to
work on it we can get it out of the way. If you want to
work on it you need to do it with all the layout
interactions.
Florian: I'm willing to work on it and the interaction with
layout, but working on multi-col in the whole is more
than I can take on. I can work on this feature, but not
the entire module.
fantasai: I don't have a problem with you trying, but I want you
to keep in mind that it wouldn't fit together unless
multi-col has more riggor.
Florian: I'm happy to keep it somewhere else, but dropping from
all specs is a bad signal.
fantasai: I don't want it in page floats because it's not a page
float. We drop it or put it in multi-col
glazou: That makes sense.
<SteveZ> +1 to fantasai's position
<tantek> +1 fantasai
Florian: Are we comfortable with starting a new level of multi-col
and I put that there?
<dauwhe> +1 to put in multicol 2
<Bert> +1
fantasai: Start an ED and put it there with an issue where the
rest of multi-col has to go there.
glazou: Is there agreement on that?
<johanneswilm> +1
glazou: Objections?
RESOLVED: New ED for the next level of multi-col
Florian: Should I add the level 1 editors to level 2?
glazou: So editors. Florian you'll be an editor?
Florian: I can be for that part, but not the whole spec. I'd like
the previous editors to stick.
fantasai: That was Hakon.
Florian: I think we have a resolution to add Rossen as well.
glazou: Since Rossen isn't here, I suggest you start with just
yourself and we'll add new editors.
Florian: I can respond to comments on multi-col on other topics,
but I can't commit at lot of time.
RESOLVED: Add just Florian as editor for the time being
Media Queries
=============
glazou: There's 3 remaining issues for Media Queries.
<glazou> https://lists.w3.org/Archives/Public/www-style/2015Mar/0419.html
Florian: Do we have TabAtkins?
glazou: He's calling shortly.
Florian: Let's wait for him.
glazou: jdaggett are you on for your topic?
glazou: dbaron you had an issue?
<glazou> https://lists.w3.org/Archives/Public/www-style/2015Mar/0508.html
dbaron: Didn't TabAtkins say he fixed it? I don't think it needs
telecon time either way.
<dbaron> yes, tab said he fixed it in
https://lists.w3.org/Archives/Public/www-style/2015Apr/0265.html
<glazou> thanks dbaron
<media-condition> grammar requires unbounded look ahead
-------------------------------------------------------
<Florian> https://lists.w3.org/Archives/Public/www-style/2015Mar/0419.html
Florian: The first issue is this, raised by SimonSapin.
Florian: The spec is phrased in a way that it requires unbounded
look ahead. It can be expressed equivalently. Re-
phrasing to make it so would be possible, but would make
the spec hard to read.
TabAtkins: I'm fine with rephrasing. We have the railroad diagrams
to make it easier to read. I'm fine with getting the
grammar to point to better impl.
Florian: I was worried about the prose afterwards.
SimonSapin: We did make a similar change to paged media spec of
the same reason, but it's not clear if it's a
requirement or a goal of CSS specs to not have look
ahead or if that's just impl detail.
TabAtkins: I think it is a strong goal. Given we did it with paged
media, I'm fine with rephrasing it. It's fine.
Florian: Let's give it a shot and if it gets horribly confusing we
can back up.
TabAtkins: Worst case I put a note with an alternative approach
that doesn't have the unbounded look ahead.
@media not(unsupported-media-feature) vs
@media not(unsupported+syntax)
--------------------------------------------
Florian: Next is this:
<Florian> https://lists.w3.org/Archives/Public/www-style/2015Mar/0514.html
Florian: Currently the <general-enclosed> parts of MQ work the same
as @support. That's prob a mistake because @support
returns false when it can't parse, which is sensible,
since something that cannot be parsed is certainly not
supported. But that's a problem for MQ. Just because you
can't parse something doesn't mean anything with regards
to the environment. It should have the same error
handling where it invalidates the entire MQ.
SimonSapin: This matters because it adds a not operator that can
be used anywhere in MQ.
TabAtkins: [pondering noise]
Florian: Were you trying to make sure why you disagree? Do you
have a reason to think it might be better the other way?
TabAtkins: I recall us discussing this specific case where you
'not'ed a thing that was invalid and I don't recall the
conclusion.
Florian: Back when you could only 'not' the whole thing this
wasn't as bad.
TabAtkins: I think this was when we added the boolean logic.
Florian: I don't recall that discussion, but I think MQ and
@supports should be different here.
TabAtkins: I'm provisionally okay with this. I'll find the old
discussion and re-raise it if I find an issue.
Florian: So should we resolve, or wait for you?
TabAtkins: Resolve now. The argument is good. If I find a reason
why it's this way I'll re-open.
fantasai: There is a special case for media type where if you
don't recognize the type you're not that type.
Florian: Yeah, I'm not changing that. Just the enclosed part of
the grammar.
SimonSapin: What's is the change?
TabAtkins: Change the error handling so general enclosed stays as
it is, if it matching the entire thing it invalidated
the entire thing.
SimonSapin: Isn't that the same as others?
Florian: It is. Currently though it works as @supports.
SimonSapin: But changing the evaluation would be the same thing as
removing entirely I think. Error handling where if you
don't match the grammar it's false.
TabAtkins: I think you're right.
Florian: You're probably right.
Florian: So let's just remove it.
fantasai: So let's say you have an unknown thing and 'or' and a
known thing that's right. You want it to be true.
TabAtkins: Yes, I think so.
fantasai: That should work. We shouldn't throw out the entire MQ.
Florian: With not it's not.
TabAtkins: General enclosed can falsify up to the nearest 'or'.
Florian: I agree with TabAtkins and fantasai.
TabAtkins: I believe that's what I was thinking of to look up. In
that case let's talk about having general enclosed
falsify to itself. A real syntax error with false the
whole thing.
<zcorpan> "A media query that does not match the grammar in the
previous section must be replaced by not all during
parsing." http://dev.w3.org/csswg/mediaqueries/#error-handling
<SimonSapin> maybe or X = X; maybe and X = maybe; not maybe =
maybe
<dbaron> Which of these are incompatible changes to media
queries?
SimonSapin: What if we have a tri-state logic?
TabAtkins: Yeah. There is a bottom value.
dbaron: So MQ right now only have 'and'?
TabAtkins: Correct.
Florian: I think we got the right behavior, but since we hadn't
considered this before the call, you or I should propose
to the ML and resolve next week.
TabAtkins: No resolution for now, we'll discuss, if there's no
objections we're good.
Allow custom MQ before @import
------------------------------
Florian: Next one is more involved.
<Florian> https://lists.w3.org/Archives/Public/www-style/2015Apr/0017.html
Florian: TabAtkins do you want this one?
Florian: It's if custom MQ can appear before @import and that
whole thing.
TabAtkins: The definition of custom MQ has no restrictions on
where they're placed. Standard behavior. This means
standard import rules do restrict them. It might make
it difficult to make an import conditional on a custom
MQ.
TabAtkins: That should still work. Never mind.
TabAtkins: You can have an import conditional on a custom MQ, but
it might take time to start loading. There's the
further question of how to handle loops, part where
there's a custom MQ in a MQ block and they're referring
to each other. You can't exclude from being inside MQ
because at minimum a conditional import applies to this.
TabAtkins: So, I believe the rules should be if a cycle is
detected in MQ rules, if a custom MQ depends on one it
contains then that MQ name gets tainted and all
instances are invalid and undefined.
TabAtkins: This is similar to the custom property loop handling.
If you get a loop in custom property it kills it and
you can't recover until the cascade is changed to
remove the loop. That's true here.
fantasai: What's the case for making these conditional on
anything?
TabAtkins: Being able to set up a set of variables on arbitrary MQ
is good and setting up MQ based on that is good. Like
on narrow screens the relevant values are foo and bar,
but there are other relevant values on a bigger screen.
Florian: Another thing you can do inside a conditional is custom
@support.
fantasai: Wait...okay...
TabAtkins: Producing and arbitrary large condition and wrapping it
as an easy MQ name.
fantasai: oookay. (doubtfully)
Florian: Another thing from the ML is that we may want for
preloader reasons to restrict them to only the top of the
style sheet. That's not entirely orthogonal. We can just
say if they're nested they do nothing, but that's a fast
way to preload.
TabAtkins: Yoav, who did a lot of work on the preloader for Blink,
where it is fine for finding import urls, no one
implements viewport parsing in preloader and he thinks
that's a bad idea. Custom MQ lie somewhere in the
middle of those things for difficulty. It's harder than
a URL. My alternate proposal is we define a new meta
value for HTML that lets you define a custom MQ up
there that can be accessed by preloaders. Ones in style
sheets are not.
Florian: So you keep the possibility of custom MQs.
TabAtkins: Yeah, they're not valid for things that require
preloaders. You can still do it, but it'll evaluate to
false during the preloading stage.
Florian: I'm comfortable with that. I suggest we try and resolve
on allowing @import and @custom MQ in the same place.
Florian: And we have when you have a loop in custom media you
invalidate the entire thing.
TabAtkins: I can poke the HTML group for that.
Florian: Because we can do that we shouldn't block the rest.
TabAtkins: Yeah.
fantasai: I'm not 100% sold on all these things. Can we do a
simpler set? You can do custom media rules, but if you
do them they come before @import.
Florian: You still need to define how loops work because you can
define media attributes. Since we have do deal with it,
I'm not comfortable cutting this off from authors.
<tantek> this sounds like it needs more thought
<tantek> f2f topic?
glazou: We can't resolve on the call. This is complex.
Florian: I think TabAtkins and I agree, so we'll make a complete
proposal on the ML.
Action Florian to write a proposal for the mailing list
<trackbot> Created ACTION-681
Action TabAtkins to write a proposal for the mailing list
<trackbot> Created ACTION-682
Font MIME types
===============
<glazou> https://lists.w3.org/Archives/Public/www-style/2015Apr/0027.html
ChrisL: Anne is correct. We do this because when @fontface was
first discussed we wanted a new top level media type.
Others hated it and we gave up and had this hokey string
instead. One one hand I'm concerned about font media types.
However, fonts are supposed to be in the registration
tree, but they're not and the web ignores this.
ChrisL: The font group has put WOFF2 and has defined the whole
tree as a new font-* which answers the question of where a
definitive list should be.
<ChrisL> http://www.w3.org/TR/WOFF2/#IMT
<zcorpan> or use text/plain, text/html, application/octet-stream...
<tantek> +1 for font/
TabAtkins: She's not wanting all the changes in CSS, they just
thought CSS was a place for a definition.
ChrisL: Having it in CSS3 Fonts is a place, but I'm pointing out
there is a spec where it is. I'm not convinced we need to
register these things, but they've decided to do that.
glazou: So Anne wanted to know where to put a list of font types.
So I guess making that spec the answer is enough?
ChrisL: Yes.
glazou: Did you contribute to the thread?
ChrisL: No, but I can.
TabAtkins: Note the font-* types aren't sufficient for the request.
The Google analysis has several not listed fonts with
decent usage. Where is this going?
<TabAtkins> Full list:
https://lists.w3.org/Archives/Public/www-style/2015Apr/0224.html
ChrisL: It's a WOFF2 appendix.
TabAtkins: It doesn't have application-* types.
ChrisL: We can add that.
TabAtkins: That's what I wanted to check.
ChrisL: I just wanted to have discussion here.
fantasai: So out of scope, forward to fonts working group
ChrisL: Yep.
RESOLVED: Font MIME type registration is out-of-scope for CSSWG,
FontsWG has a (partial) list, forwarding issue to them
Allow Extended Hebrew Counters
===============================
glazou: We have 10 minutes and 4 things on the agenda.
<glazou> https://lists.w3.org/Archives/Public/www-style/2015Apr/0117.html
TabAtkins: Hebrew counts is easy. I'm fine adding that
implementors can do larger Hebrew counters if they want
to.
<Florian> +1
fantasai: I'm fine with that.
glazou: So is there objections?
<Bert> (no objection)
RESOLVED: Add that people may support larger Hebrew counters if
they want
glazou: Do we have someone from LG on the call?
fantasai: We need a resolution to re-publish counter styles CR for
this.
glazou: Okay, objections?
<andrey-bloomberg> +1
<Florian> +1
<astearns> +1
<dauwhe> +1
<zcorpan> +1
Bert: No objection.
<tantek> +1
RESOLVED: Re-publish Counter Styles CR with the above addition
<fantasai> Tab, don't forget to add to blow away the changes list
and replace it with the change above :)
Ruby inlinize algorithm
=======================
TabAtkins: I was asking fantasai if she had comments. It's
relevant to other cases.
fantasai: I need to dig deeper into this.
Addition of a ::flex-line pseudo-element
========================================
fantasai: We might want to consider it for a future level of
flexbox.
TabAtkins: I agree.
fantasai: Definitely not adding it now.
glazou: So that's what we can do without LG. Anything for the
remaining minutes?
Florian: I have more, but don't remember length.
glazou: Okay. Anything else?
Naming issue for cursor: default
================================
Florian: Just sent a mail where we have a naming collision about
the default value.
<tantek> yay. cursor: default; vs. *: default
TabAtkins: When was that added to cursor?
tantek: CSS2.
TabAtkins: Okay.
fantasai: And default was reserved in CSS2.
TabAtkins: Yeah. Okay.
fantasai: It's in the font section.
<tantek> time to dig through CSS2 WDs :P
Florian: I can think of 3 options. One is you can't use global
default on cursor. That would be unfortunate. We can
rename the global. Or we can create a horrible special
value like 'default-I-mean-it' for the cursor property
<ChrisL> I wouldn't worry about using values we haven't reserved
TabAtkins: The default isn't arrow for historical reasons, right?
Florian: Yeah, but it's too late to rename.
Florian: So anyone have a better idea?
glazou: I'm sure we're going to hate all the ideas.
tantek: Least worst is cursor doesn't get the global default for
now.
<astearns> +1 to tantek's position
Florian: What about later?
tantek: You worry when there's demand.
Florian: The default isn't supported by anyone now. If we rename
now we don't have a problem later.
glazou: And not putting a special case in the code.
tantek: Sounds like research is needed about applying default to
something else. For the global default name. We need to
research the bikeshedding.
TabAtkins: That's the least unattractive option. We need to see
what's been used and what's free on the ML.
tantek: Can bikeshed figure that out?
TabAtkins: It doesn't know literally all the properties because
some specs aren't in bikeshed.
glazou: Who will do the research?
TabAtkins: Let's suggest things on the ML. Research is pretty easy.
Florian: One down side is that default has been reserved for
authors as well, but nothing else has so we may conflict
with author names.
TabAtkins: It's generally unlikely. There's only a few places
authors can use custom names so I don't think we'll
infringe.
Florian: Let's try that on the ML
glazou: Let's move it to the ML.
glazou: Thank you very much and talk to you next week.
<Bert> (Maybe replace by two values: user and ua, to reset to user
style and UA style resp.)
<TabAtkins> Bert: 'default' currently resets to the user level
when used in author sheets, and to the UA level when
used in user sheets.
<TabAtkins> Bert: I don't think there's any reason to let the
author explicitly reset down to UA, skipping the user
styles.
<Bert> That's my intuition, too, but I'm just brainstorming...
<tantek> What TabAtkins and Bert said.
<tantek> in addition, *allowing* the author to skip user styles
goes against our design principles
<zcorpan> 'ua-default' (with same semantics as now; people don't
know or care about user styles)
* fantasai is now wondering if we need to rename 'default' to
'unset' and 'unset' to 'reset'
<SimonSapin> fantasai, isn’t unset shipping?
<fantasai> SimonSapin: probably. And probably the people using it
don't know the difference :)
<TabAtkins> Yeah, and "unset" still works fine for its current
name - it unsets *everything*.
<TabAtkins> But yeah, I'll bet some people using "unset" are
expecting it to give UA defaults. ^_^
Received on Thursday, 23 April 2015 15:36:19 UTC