Re: [CSSWG] Minutes Telecon 2013-05-22

I was also present.


On Wed, May 29, 2013 at 2:43 PM, fantasai <fantasai.lists@inkedblade.net>wrote:

> Summary:
>   - RESOLVED: Publish Counter Styles as LC, 4-week period, contact HTML,
>               i18n, a11y for feedback.
>   - RESOLVED: Publish FPWD of Shapes, updated WD of Exclusions.
>   - RESOLVED: Publish a new WD of Regions.
>   - Discussed adding Sunday to TPAC meeting
>   - Discussed an+b grammar changes in Syntax 3
>   - Reviewed issues wrt computed values of font-relative lengths
>     vs. font-size-adjust, font size availability
>   - RESOLVED: No change for ID selector syntax: must be identifier.
>               This is consistent with implementations and class selectors.
>   - Brought up issue of background-attachment: local positioning
>       http://lists.w3.org/Archives/**Public/www-style/2013May/0516.**html<http://lists.w3.org/Archives/Public/www-style/2013May/0516.html>
>
> ====== Full minutes below ======
>
> Present:
>   Rossen Atanassov
>   Tab Atkins
>   Shezan Baig
>   Bert Bos
>   Justin Erenkrantz
>   Elika Etemad
>   Sylvain Galineau
>   Daniel Glazman
>   Philippe Le Hégaret
>   John Jansen
>   Peter Linss
>   Anton Prowse
>   Simon Sapin
>   Dirk Schulze
>   Alan Stearns
>   Nick Van den Bleeken
>   Lea Verou
>
> <RRSAgent> logging to http://www.w3.org/2013/05/22-**css-irc<http://www.w3.org/2013/05/22-css-irc>
> Agenda: http://lists.w3.org/Archives/**Public/www-style/2013May/0507.**
> html <http://lists.w3.org/Archives/Public/www-style/2013May/0507.html>
> Scribe: TabAtkins
>
>
> <SimonSapin> Did we resolve on ID selector syntax?
>              http://www.w3.org/Style/CSS/**Tracker/issues/316<http://www.w3.org/Style/CSS/Tracker/issues/316>
>
> Publicatoins
> ------------
>
>   plinss: You wanted last call on Counter Styles?
>   TabAtkins: Yes.
>   plinss: Any objections?
>   plinss: Anyone need contacting about it?
>   TabAtkins: I'd to HTML, i18n, and a11y.
>   RESOLVED: Publish Counter Styles as LC, 4-week period, contact HTML,
>             i18n, a11y for feedback.
>
>   plinss: Next, exclusions and shapes.
>   stearns: I've split the specs, and want to publish WDs for them.
>   plinss: For Shapes, is that FPWD?
>   <ChrisL> yes it will be a fpwd
>   stearns: I'm not sure what the process is about splitting.
>   fantasai: Process-wise it's a FPWD.
>   plinss: Objections?
>   <fantasai> stearns, they key point is that a shortname has to be
> approved :)
>   RESOLVED: Publish FPWD of Shapes, updated WD of Exclusions.
>   krit: If we publish a new FPWD, we'll need a new IP review.
>   <ChrisL> only for anything not already published, I believe
>   <Bert> (New WD needs domain lead approval, that would be for Shapes.
>           I can take care of that with PLH.)
>   ChrisL: In the Status of the draft, it's customary to say that it was
>           previously published as XXX and has been split out.
>   ChrisL: So it would be pretty hard for people to exclude anything.
>   plinss: But we still have to go through the exclusion period?
>   ChrisL: Unfortunately, yes.
>
>   plinss: Also, you want a new WD of Regions?
>   stearns: Yes, just a heartbeat draft with latest updates.
>   Rossen: I'm good for another publish.
>   RESOLVED: Publish a new WD of Regions.
>
> TPAC
> ----
>
>   plinss: Anyone want an extra day before/after TPAC, like we did last
> year?
>   Rossen: Would that be Sunday?  I'm in favor.
>   <leaverou> +1 for extra TPAC day
>   plinss: Likely, yes.
>   krit: Also, there's a TTWF on Saturday.
>   Bert: I may have additional requirements around TPAC.  I probably won't
>         have time.
>   plinss: Okay, so let's do some research and see if we can get meeting
>           space.
>
> an+b grammar
> ------------
> Scribe: fantasai
>
>   TabAtkins: an+b has always been defined handwavy, at best with completely
>              different tokenizer than CSS
>   TabAtkins: Had to retokenize or do some other magic
>   TabAtkins: In Syntax, defined it based on CSS tokens
>   TabAtkins: Change from Selectors 3 is that in case of "+n", can
>              have a space between sign and 'n'
>   TabAtkins: This is because [...]
>   TabAtkins: This is unavoidable if we define in terms of [...]
>   TabAtkins: It's a minor change
>   TabAtkins: dbaron has an objection to it because can't just swap + and
>              minus and be correct
>   TabAtkins: I think it's a very minor thing. There is no reason to ever
>              write +n
>   TabAtkins: Anyone have thoughts about this?
>   <ChrisL> presumably calc does not affect this
>   ChrisL: [...?]
>   ChrisL: Nevermind
>   dirk asks for a link to discussion
>   <SimonSapin> http://www.w3.org/mid/**0bgmqpl2196wrcmj2q786i4q.**
> 1368261406596@email.android.**com<http://www.w3.org/mid/0bgmqpl2196wrcmj2q786i4q.1368261406596@email.android.com>
>   glazou: The only bit I don't get is when you say that it used completely
>           different tokenizer than CSS, because we carefully designed
>           an+b long ago to use units and stuff like that, to be able
>           to go through the tokenizer
>   TabAtkins: If that was your intent, it got lost.
>   TabAkins: [ explained how various things get merged into single tokens]
>   TabAtkins: Tokenizer as written is Selectors and in CSS2.1, not
> compatible
>              with CSS tokenization rules
>   <Bert> (It *is* compatible. You just have to re-parse it afterwards.)
>   fantasai: Tab is right, you can tokenize everything that's inside an+b,
>             but you have to retokenize in order to parse it.
>   fantasai: I don't think we should be changing anything right now.
>
>   <ChrisL> is a+/**/b already allowed?
>   <SimonSapin> ChrisL, unclear per Selectors 3
>   TabAtkins: It's a change that falls out of how I'm defining it.
>   "+ n" and "- n"
>   <SimonSapin> Syntax 3 tries to make it more well-defined
>   glazou: we originally wanted whitespaces allowed but did not go that
>           way because of our parsing rules at that time
>
>   plinss: your current change allows space after plus, but not after minus?
>   TabAtkins: Yes, because can't tell the difference in tokenization between
>              "+n" and "+ n" if you're ignoring space tokens
>   glazou: I don't think it's good to have differences in + and -.
>   * Rossen + 1
>   glazou: Should allow for both or disallow for both, otherwise it's
> confusing.
>   <ChrisL> and that would address dbaron's objection too
>   krit: I agree with that.
>   <SimonSapin> +1 for consistency
>   TabAtkins: Ok, sounds good to me. we'll wait for dbaron now.
>
> font-size-adjust
> ----------------
>
>   ScribeNick: TabAtkins
>   <SimonSapin> http://lists.w3.org/Archives/**
> Public/www-style/2013May/0384.**html<http://lists.w3.org/Archives/Public/www-style/2013May/0384.html>
>   fantasai: The issue is that in CSS3 Fonts, we need to be clear about what
>             the font-relative lengths are computed against.
>   fantasai: em, ex, ch
>   fantasai: The computed font-size is a length, and that's known.
>   fantasai: But there's various things that can affect the resulting,
>             actually used, font-size.
>   fantasai: Like font-size-adjust.
>   fantasai: Or size substitution.
>   fantasai: (the spec lets the size be rounded tot he nearest pixel, or
>              the nearest bitmap size)
>
>   fantasai: So is an em the computed font size, or the font size after
>             you do those adjustments?
>   ChrisL: It seems like it should be as early as possible.
>   ChrisL: If you take what's specified and produce a used size, you're
>           having to do the process twice.
>   TabAtkins: em size can't depend on nearest bitmap size, since that
> depends
>              on url resolution, and computed values don't depend on that.
>   fantasai: But ex and ch depend on font metrics anyway.
>   fantasai: We could say that em is a computed value, while ex/ch wait
>             until the font data comes in.
>   <SimonSapin> +1 for em = computed font-size, ex and ch based on the used
>                font size
>   ChrisL: I think that's consistent with what I said, where it resolves
>           "as early as possible".
>
>   Bert: Given the use-case for ex, that should be done after
> font-size-adjust.
>   Rossen: What use-cases are we addressing?
>   <Bert> (One use case for ex I found is to make a bar that looks like:
>           xxxxxx Page 7 xxxxxxxxx where the x is actually a solid bar
>           that matches the lowercase letters. I have a photo somewhere...)
>   <TabAtkins> (Bert - another is to use images for non-text glyphs that
>                are meant to be lowercase-letter sized.)
>   fantasai: An em unit is generally used for having margins/padding be
>             some multiple of the font size.
>   fantasai: For ch, if you have a monospace font, you want to size
> something
>             to some fixed number of characters from that font.
>   ChrisL: font-size-adjust tweaks font sizes so that if several fonts are
>           used together, they all have the same "middle height".
>   ChrisL: And it seems reasonable to size things relative to that.
>
>   fantasai: So I feel pretty strongly that ch should be resolved after
>             font data.
>   fantasai: For em I feel less strongly, but there are questions.
>             What's the line-height if you set it to 1em, and then the
>             size of the font is tweaked?
>   fantasai: Whatever the line-height ends up being, it would be useful
>             to have em be that measurement.
>
>   fantasai: But I think that relevant people aren't here.  That's the
>             overview of the issue.
>   plinss: I think dbaron sent his regrets next week, so maybe push it to
> the f2f?
>
> ID Selectors Grammar
> --------------------
>
>   <SimonSapin> http://www.w3.org/Style/CSS/**Tracker/issues/316<http://www.w3.org/Style/CSS/Tracker/issues/316>
>   SimonSapin: I'd like to talk about the id selector grammar issue.
>   SimonSapin: We have a proposed change to relax the restriction, so ID
>               selectors can just be any hash token (no requirement for
>               the value to be an ident).
>   SimonSapin: But there's another argument that we should keep the
>               restriction, to be more consistent with class selectors.
>   fantasai: The counter-argument makes sense to me.
>   fantasai: And we have interop on that behavior, so I'm happy to keep
> that.
>   TabAtkins: Removing the restriction simplifies the spec (I don't have
>              to keep around a flag on hash tokens), and it means we can
>             remove the quirk that relaxes the restriction.
>   Bert: Seems dangerous to make the change at this point, since it's so
> old.
>   TabAtkins: It's only dangerous if there are rules that are currently
>              invalid due to having a non-ident hash as an id selector,
>              and which the page depends on being invalid.
>
>   [something about the quirk not existing in all browsers]
>   plinss: The quirk is not present in FF, Safari/Chrome.
>   ChrisL: HTML *does* allow non-ident IDs.
>   <SimonSapin> http://lists.w3.org/Archives/**
> Public/www-style/2013Apr/0190.**html<http://lists.w3.org/Archives/Public/www-style/2013Apr/0190.html>
>                "Not if we want to drop the quirk. This quirk is not present
>                 in Firefox/Safari/Chrome. That means we can drop it."
>
>   fantasai: Given the argument for consistency with class selectors,
>             that we have interop across all implementations right now,
>             and that the quirk can be dropped because it's not implemented
>             across all implementations anyway, I strongly think that we
>             should not make this change.
>   glazou: Agreed - changing classes to/from ids is common, and if having
>           to change the syntax, that's painful.
>   * ChrisL can see arguments both ways
>   RESOLVED: No change for id selector syntax.
>
> background-attachment: local
> ----------------------------
>
>   fantasai: Question about backgrounds.
>   <fantasai> http://lists.w3.org/Archives/**Public/www-style/2013May/0516.
> **html <http://lists.w3.org/Archives/Public/www-style/2013May/0516.html>
>   fantasai: There used to be background-attachment: scroll | fixed
>   fantasai: scroll meant the background scrolled with the content.
>             fixed meant the background didn't scroll with the content.
>   fantasai: CSS2 added 'overflow', which allowed any element to have a
>             scrollbar.
>   fantasai: The WG decided that 'scroll' should act like 'fixed' for
>             those elements.
>   fantasai: We added the 'local' value to get back to scrolling background
>             and content together.
>   fantasai: So I want to clarify the spec to define the positioning area.
>   fantasai: So it matches the way the canvas background works inside the
>             viewport scroll area.
>   TabAtkins: I want a picture.
>
> plinss: No further topics, so adjourned.
> Meeting closed.
>
>