- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 18 Mar 2015 17:52:27 -0400
- To: www-style@w3.org
<custom-ident>
--------------
- RESOLVED: Exclude the global keywords from <custom-ident>.
- RESOLVED: Pending edits, publish Values & Units as new CR.
Flexbox
-------
- The spec is close to a new release, just has a few more edits to
do.
Form Control Styling
--------------------
- In order to keep the good discussion on the mailing list going,
Florian will make a list of the proposals so far and everyone
was asked to collect screenshots of form controls to style.
CSS Snapshot
------------
- RESOLVED: Produce the snapshot with list below, update vendor
prefix policy. Group will review when finished.
* Everything in REC
* Animations L1
* Backgrounds and Borders L3,
* Cascading and Inheritance L3
* Compositing and Blending L1
* Conditional L3
* Flexible Box Layout L1,
* Fonts L3
* Images and Replaced Content L3
* Multicolumn Layout L1
* Syntax L3
* Transforms L1
* Transitions L1,
* Values and Units L3
** plus will-change and CSS3 UI once stable updates
are published to TR
- Plan to incorporate intro material from CSS2.1 in next update
- Plan to incorporate property indices/glossaries/etc. once we can
generate them for an entire snapshot
CSS 2.1
-------
- RESOLVED: Add a note to every subsection of CSS2 pointing to
drafts that replace those parts of CSS.
Obsoleting CSS3-Linebox
-----------------------
- RESOLVED: Ask Chris to put an obsoletion notice on the current
CSS3-Linebox on TR.
===== FULL MINUTES BELOW ======
Scribe: TabAtkins
<custom-ident>
--------------
SimonSapin: We have an issue when <custom-ident> can occur at the
same position as keywords, could be ambiguous.
SimonSapin: Need to define how to resolve.
SimonSapin: Right now the spec says that the first occurrence of
something ambiguous is given to the keyword, and
afterwards is <custom-ident>.
SimonSapin: But that means you have to remember what you've parsed
so far.
SimonSapin: That's annoying to implement, and maybe surprising to
authors.
SimonSapin: If you reorder things where order normally doesn't
matter, it changes the meaning.
SimonSapin: Another option is to restrict <custom-ident> based on
what it can be ambiguous with.
SimonSapin: For example, list-style-type takes either
<counter-style> | string | none
SimonSapin: And <counter-style> is <custom-ident>.
SimonSapin: So if you specify "none", it can't be a
<counter-style>, as it'll be ambiguous.
SimonSapin: But that's easy.
SimonSapin: In list-style, at the same position as you would have
a <counter-style>, you might have "outside" keyword, a
valid list-style-position value.
SimonSapin: So here we should restrict <custom-ident> to not be
able to be "outside".
dbaron: So you'd restrict "outside" from list-style-type as well?
SimonSapin: That's possible, but it's harder to maintain.
TabAtkins: We explicitly rejected the "exclude keywords from all
contexts it can be used", because that set is large and
ever growing, and confusing to think about.
TabAtkins: We also purposely moved away from the simpler "exclude
keywords from the current context", because it still
makes it hard to extend the set of keywords in the
future; they might be used by authors.
TabAtkins: We purposely moved to the current behavior, which
matches animation, to avoid those problems.
SimonSapin: Describe current animation behavior?
TabAtkins: What the spec currently says - <animation-name> only
claims unknown keywords, or known keywords that
correspond to properties that are already set by
earlier keywords.
TabAtkins: So you can name an animation "forwards" as long as you
also always specify the animation-direction part of the
animation shorthand, and put the animation-name at the
end.
SimonSapin: That means in a context where order normally doesn't
matter, sometimes it does and you can't.
TabAtkins: Right.
TabAtkins: All new grammars should always be positionally
unambiguous.
TabAtkins: The only reason we have this problem is old properties
that get upgraded to <custom-ident>, so something that
wasn't ambiguous becomes ambiguous.
<dbaron> The values spec should probably say that (i.e., give
advice for spec authors).
TabAtkins: Are you okay with this, given that context?
SimonSapin: Okay, I can live with this. I'd like to explore other
options, but maybe in a later meeting.
TabAtkins: Next is global keywords - allow or exclude? I don't
care.
fantasai: Weak preference for excluding. I don't think there's any
reason to allow them, and they cause some problems.
fantasai: And we already exclude them in font-family and
counter-styles.
fantasai: It's better to catch errors earlier, so it's a benefit
to authors and just exclude it.
TabAtkins: I'm fine with that - it makes it harder to add global
keywords, but we don't do those often anyway.
SimonSapin: I think it's arbitrary to exclude them when not
ambiguous, but meh.
RESOLVED: Exclude the global keywords from <custom-ident>.
SimonSapin: One remark about <custom-ident>.
SimonSapin: The spec says that other specs must clearly say what
keywords are excluded. Why normative?
TabAtkins: Why not?
(If we can put normative requirements on authors, we can put them
on spec writers, too.)
RESOLVED: Pending edits, publish V&U as new CR.
ChrisL: Remember we'll need an up-to-date DoC to republish.
Flexbox
-------
<fantasai> https://lists.w3.org/Archives/Public/www-style/2014Sep/0396.html
TabAtkins: Bug. Don't understand why Chrome and FF interoperably
don't do the right thing. IE does the right thing.
Please explain it all.
fantasai: If you have an abspos flex container, it wraps to the
window width, but doesn't shrinkwrap into it.
fantasai: We think this is wrong, just wanted to check we're not
missing something.
fantasai: Issue about no-wrap is still open
fantasai: and have some pagination stuff
fantasai: then should publish.
Form Control Styling
--------------------
<fantasai> http://dev.w3.org/csswg/css-forms/
TabAtkins: fantasai brought up form control styling.
TabAtkins: Started a nice thread.
TabAtkins: Started disagreeing on what is reasonable to allow form
control styling.
TabAtkins: Have a basic exploratory draft.
TabAtkins: It writes up various proposals. We need more
screenshots.
dino: Web controls are horrible on iPhone.
ACTION: florian to make page of all form controls
<trackbot> Created ACTION-673
fantasai: So proposal is collect screenshots.
TabAtkins: Two proposals so far, read and comment and throw out
more ideas.
TabAtkins: And really, want more screenshots. Especially from
outside Android/iOS bubble
Snapshot
--------
Scribe: TabAtkins
fantasai: Arron posted a proposal for a snapshot 2015.
<fantasai> http://www.w3.org/mid/BLUPR03MB199E2D02A3708B7400C5108AD270@BLUPR03MB199.namprd03.prod.outlook.com
fantasai: His proposal is:
<fantasai> https://lists.w3.org/Archives/Public/www-style/2015Feb/0200.html
fantasai: We need to update the snapshot.
fantasai: Introduction section needs reworking, change the
vendor-prefix section.
fantasai: But also need to decide what goes into the snapshot.
Florian: dbaron and I have also helped him iterate on this
fantasai: Proposal so far is everything in Rec,
fantasai: Also animation, backgrounds, cascade, conditional,
flexbox, fonts, images, multicol, transform,
transitions, and v&u.
fantasai: Some discussion about counter-styles.
fantasai: And syntax.
dbaron: Does anyone else implement text-decoration-3?
fantasai: I think Apple does text-emphasis?
fantasai: I'm guessing it'll wait to 2016, based on what I know.
fantasai: Any other editors think their specs are ready?
TabAtkins: There was a suggestion for the will-change spec. It's
stable and widely implemented.
tantek: I think UI meets the criteria too.
TabAtkins: Did you drop all the weird stuff that nobody
implemented?
tantek: ::value/choices not yet, but will be dropped ASAP. Then
it's all implemented stuff.
fantasai: I say we leave it out until the new draft that drops
those is up.
tantek: How long to do it?
Florian: Several bits need to be rewritten, so won't be published
for a little bit.
[some discussion about UI]
fantasai: I'd like will-change to move to CR, if it's ready to be
included in the snapshot.
dbaron: Is Syntax a yes?
dbaron: I'd like to see it in.
fantasai: If dbaron says it should go in, I'll support that.
TabAtkins: Everyone okay with Syntax in?
[general assent/disinterest]
<tantek> I don't understand the criteria being used
<tantek> appears to be inconsistently applied
SimonSapin: Anything we don't want that it's in CR?
fantasai: Speech, because no implementations.
fantasai: Text-decor not yet.
fantasai: Writing-modes not yet.
fantasai: Shapes and Masking are not in yet.
TabAtkins: Shapes is in two implementations. Sounds like it
should go in.
astearns: I think Shapes is reasonably stable, but I'd still like
another implementation.
TabAtkins: So in or not?
astearns: I dunno.
astearns: Let's leave it out. I don't expect to see changes, but
we'll see.
dbaron: I think whoever made the list didn't go through FXTF.
dbaron: Compositing, Masking, Filters, what's implementation
status?
TabAtkins: I think they're all in Blink/WEbkit.
roc: Firefox doesn't do Masking. We do Compositing and Filters.
krit: With exception of Blending, all other specs have partial
implementations, but aren't implemented entirely.
krit: So Blending should go in.
fantasai: So, Arron's list, plus will-change and UI once they're
updated, plus compositing.
fantasai: Plus Syntax.
<tantek> so we are including CSS3-UI?
<astearns> tantek: once the edits are made, yes
<astearns> tantek: same as with will-change
<tantek> astearns, edits we agreed to in this meeting? because
edits are going to be made for quite some time.
<astearns> tantek: I thought you had a set of edits to make before
publishing
<tantek> astearns, no, we already have a draft in the pipe to be
published per resolution 2015-01-21
<tantek> and I would assert event that draft is good enough to be
included
Florian: Do we inline the intro chapters from CSS2? It has a nice
introduction to CSS.
Florian: If the snapshot is the introduction to stable CSS, seems
reasonable to put that there.
ChrisL: It turns "a list of stuff" into "a list of stuff plus some
introductory material". Do people read it?
ChrisL: Will the introduction be the same?
Florian: Initially could be the same, but might change too.
fantasai: I think we should do minimal stuff first. Update list of
specs and interactions, update vendor prefixing, then
publish.
fantasai: I think we should include the intro from CSS2 about
"this is how property tables work, etc".
fantasai: And a glossary of terms auto-genned from Shepherd for
those specs.
fantasai: All this latter stuff as a second publication.
fantasai: And a property index auto-genned by Shepherd.
TabAtkins: Sounds good. We can do the minimal stuff by end of Feb,
additional publications pending interest.
RESOLVED: Produce the snapshot with fantasai's list, update vendor
prefix policy. Group will review when finished.
<SimonSapin> plinss, maybe dev.w3.org/csswg/css/ should be an
alias for the snapshot rather than 2.x, to match
http://www.w3.org/TR/CSS/
CSS 2 updates
-------------
fantasai: I think someone was proposing we should publish drafts
where we remove sections of CSS2.
fantasai: Unsure we can do that without a lot of overhead, and I'm
not sure it's a great idea.
fantasai: But we *should* put a note under every replaced
subheading pointing to the replacing draft.
fantasai: At some point in the future we can publish a skeleton
spec.
Florian: Do we put a note pointing to specs when they're Rec? Or
as soon as they exist?
TabAtkins: As soon as browsers accept them as definitive.
fantasai: CR, definitely. Earlier on a case-by-case basis.
ChrisL: You're proposing a skeletonization.
[discussion of zombie bodies of CSS2.1]
[ChrisL describes Night of the Living CSS2]
ChrisL: Apparently we have a bunch of errata to publish. I thought
that's what CSS2.2 was about?
ChrisL: Is the whole point of this to just point to the new stuff,
why roll in errata in the first place?
fantasai: I think there's some sections of 2.1 we don't have a
replacement for yet.
fantasai: Some have been replaced; their contents are still
correct and can be used as a reference, but we should
point to the newer reference.
fantasai: So if we make changes, might as well keep them in sync.
fantasai: But some sections have been completely gutted and
redesigned, like syntax.
fantasai: The warning should be more stringent and emphasize that
the new reference is very important to look at.
fantasai: We won't be maintaining any errata for syntax.
ChrisL: Are there pending errata for 2.1 that need to be
published?
ChrisL: Where is that best going to go for people to notice it?
ChrisL: The sections getting replaced should be the new stuff.
Florian: If entire sections are wrong, just say "go look at the
new stuff".
fantasai: Part of the problem is that our errata maintenance
process is unmanageable. It's too hard to publish our
errata docs.
fantasai: We can at least publish notes saying "look over here",
so we should do that.
fantasai: And also solve the errata problem, but that's separable.
ChrisL: I just wanted to make sure the errata moved from the
errata document to someplace people will actually look at
them.
SimonSapin: The editors draft contains the errata inline.
ChrisL: And there's a note on 2.1 pointing to the ED.
TabAtkins: So does anyone object to adding the notes to the ED,
per fantasai?
Florian: Is the criteria for drafts the same as the snapshot?
fantasai: No. CSS2.1 might have a terrible section that's still
being replaced by something better, but churning. It's
still good to look at the new draft, versus the CSS2 def.
fantasai: So if it's stable OR better, we should point to it.
ChrisL: How to indicate it? People can deep-link.
fantasai: A note on every subsection.
TabAtkins: Yeah, that's probably sufficiently dense that you'll
tend to see it.
Florian: Bikeshed should have something for specs to indicate they
replace something.
TabAtkins: In time!
SimonSapin: My list of replacement is my personal judgment of what
people should look at for implementation.
<SimonSapin> the list in question:
https://github.com/servo/servo/wiki/Relevant-spec-links#css-2
RESOLVED: Add a note to every subsection of CSS2 pointing to
drafts that replace those parts of CSS.
Obsoleting CSS3-Linebox
-----------------------
<dauwhe> http://www.w3.org/TR/css3-linebox/
TabAtkins: Tav from SVG keeps landing on this spec and it confuses
him. Can we fix it.
fantasai: We're going to redirect this to css-inline-3.
fantasai: I think it was supposed to be published when we did the
last draft of dropcaps, but looks like next draft.
TabAtkins: So when's the timeline?
TabAtkins: If it's gonna be this month, fine, otherwise do a note
for now.
dauwhe: Let's just do the note now.
RESOLVED: Ask Chris to put an obsoletion notice on the current
css3-linebox on TR.
dbaron: I wish I'd at some point published the linebox edits as
a WD.
dbaron: No idea where it went now.
dbaron: It's not in the draft repo as css-linebox.
Received on Wednesday, 18 March 2015 21:52:54 UTC