[CSSWG] Minutes Telecon 2013-05-22

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

====== 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
Agenda: 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

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
   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
   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
   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
                "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
   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.

Received on Wednesday, 29 May 2013 20:44:20 UTC