[CSSWG] Minutes Telecon 2014-10-08

Error-correcting unclosed empty url()
-------------------------------------

  - RESOLVED: Unclosed URLs at the end of file should auto-close
  - RESOLVED: Change the values and units to make invalid empty URL
      fail to resolve automatically

media queries "not" is inconsistent
-----------------------------------

  - RESOLVED: Remove the old text that negates the entire media
      query if an unrecognized media value or feature appears

Remove setPropertyValue and setPropertyPriority
------------------------------------------------

  - Deferred until later.

CSS Snappoints
--------------

  - MaRakow reported that now that there's interest in Snappoints
      he'll begin working on the open issues.

Sizing of floated ::first-letter
--------------------------------

  - RESOLVED: Accept pseudo elements 4 as an official ED, add
      TabAtkins as an editor, and remove the bits that aren't in
      Selectors 3

TPAC
----

  - Everyone was reminded to register if they haven't.
  - Fantasai requested that people look over the Flexbox spec and
      have any questions ready so they can move to CR either at or
      shortly after TPAC.

===== FULL MINUTES BELOW ======

Present:
  Tab Atkins
  Bert Bos
  Adenilson Cavalcanti
  Dave Cramer
  Alex Critchfield
  Bruno de Oliveira Abinader
  Elika Etemad
  Simon Fraser
  Sylvain Galineau
  Dael Jackson
  Philippe Le Hégaret
  Chris Lilley
  Peter Linss
  Edward O'Connor
  Anton Prowse
  Matt Rakow
  Florian Rivoal
  Dirk Schulze
  Mike Sherov
  Alan Stearns
  Greg Whitworth

Regrets:
  Rossen Atanassov
  David Baron
  Daniel Glazman
  Mike Miller
  Simon Pieters
  Lea Verou
  Steve Zilles

  Scribe: dael

  plinss: Let's get started. Any additions?
  plinss: I'll take that as a no.

Error-correcting unclosed empty url()
-------------------------------------

  TabAtkins: That's mine.
  TabAtkins: There are two cases that zcorpan pointed out to me.
  TabAtkins: They may vary from handling in the old spec. When the
             URL function is unclosed like this in IRC:
  <TabAtkins> foo { background-image: url(image
  TabAtkins: If that is an entire stylesheet, browsers are
             inconsistent. Firefox and IE follow the spec and close
             the URL and treat it as valid. Chrome says it's invalid.

  <TabAtkins> foo { background-image: url(
  TabAtkins: If that (above) was the entire function, this is
             inconsistent too.
  TabAtkins: Firefox and Blink throw as invalid. IE is valid and
             treats it link an empty URL
  TabAtkins: That exposes interesting bits of URL handling that's
             something I'll talk on later after we decide this.

  TabAtkins: On these examples I'd like to standardize on the IE
             behavior. First example is valid and closes, second is
             valid and points to empty. This is consistent with
             error handling for other items.
  TabAtkins: So this would be consistent with functions and matches
             IE. This is what the spec currently says.
  TabAtkins: I want to make sure that's okay because this may be a
             change from old syntax, but it's hard to tell.

  plinss: My guess would be it's from tracking URL as a token. I
          think this makes sense. My question is, is it spec'ed this
          way or it is ambiguous?
  TabAtkins: Spec is unambiguous. If there's a string there it's
             super easy, but these are non-string so they're handled
             by special token. The only way to have a bad URL is to
             have a bad character in there. Unclosed and empty
             should do the same thing. It's hard to omit a bad URL.

  plinss: Does anyone think TabAtkins' proposal is the way it should
          not work?
  fantasai: I'd like a clear summary in IRC and I'd like dbaron to
            sign off explicitly since he might know some
            compatibility issues.
  TabAtkins: URL functions auto-close same as other functions in CSS.
             As to compatibility, we're doing the IE behavior, so
             it's unlikely to be a problem.
  plinss: This is only end of file?
  TabAtkins: Yes. The only place we care about end of file is for
             strings.
  plinss: fantasai, do you want dbaron to sign off still?
  fantasai: I'm okay with having a resolution, but I want to hear
            back from him.
  TabAtkins: I'm okay with that too.

  <Bert> (Boris Zbarsky may know if this causes problems with look-
         ahead.)
  <gregwhitworth> FWIW: We have no bugs regarding the
                  background-image url() EOF that Tab suggests

  RESOLVED: Unclosed URLs at the end of file should auto-close

  TabAtkins: There's a quirk to this that I discovered. What to do
             about an empty URL. This is a value and units issue. We
             uncovered this in IE's behavior for the second example.
  TabAtkins: Blink and Firefox are consistent that empty URL is
             invalid. IE treats an empty as unresolvable.
  TabAtkins: That matches HTML in similar cases. If you provided an
             empty tag it's an error for image. In general empty
             URLs are errors. It's only in linking where they're
             allowed.
  <fantasai> IIRC people link to the current page often for
             javascript-triggered links

  TabAtkins: This seems reasonable to me, but it's not a big deal.
             It seems it might be reasonable to converge on IE since
             it matched HTML.
  TabAtkins: It means we might need a flag around URLs that weren't
             empty. So if we had hyper-linking we could allow an
             empty URL
  TabAtkins: All ours right now are resource requests, but we may
             need that in the future.
  TabAtkins: An image is a valid declaration, but pointing to an
             empty URL.
  <fantasai> Like url(about:invalid)?

  florian: So instead of trying to figure out if it's empty after,
           you give up before?
  TabAtkins: Yes. I think this only shows up around error handling
             since normally an empty URL for an image is an error
             anyway.

  fantasai: In values and units for the attr function if you return
            the default URL, it is about:invalid
  TabAtkins: I believe it should resolve the absolutization process
             and should resolve to invalid the same way.

  plinss: This is something that should be done blanket-ly at parse
          time, or should it be more usage time depending on how
          it's used?
  TabAtkins: In the future we may have linking style things and
             those should be valid, but we don't right now. However,
             to plan for the future I'd rather it be at the values
             and units level
  plinss: I agree.
  fantasai: I wouldn't agree with syntax level, but I don't have an
            opinion for interoperability. I can't think of an answer
            other than invalid.
  fantasai: If it returns the current page, it would return the
            stylesheet itself.
  TabAtkins: Unless it's inline.
  fantasai: And that would be invalid most times since you're
            looking for an image.
  TabAtkins: In general it'll fail to resolve, but it means a second
             pass is required if you're not caching. For something
             you're likely to fail, I think we should have it be
             first time.
  <fantasai> @import url();
  <fantasai> :)

  plinss: In theory someone could be doing something really bad, but
          I think in practice it's fine.
  florian: Or perhaps there's someone altering it strangely. I'm
           sure it's possible with loose syntax, but we don't need
           to support this use case.
  TabAtkins: Yep.

  plinss: I agree. Some people use png to compress script.
  plinss: I don't know how, but it's a thing.
  plinss: I don't know exactly what, I haven't looked into it.
          They're using png compressor on the script.
  <ChrisL> png compression is zlib/flate
  florian: If it works, good for them.

  * fantasai would like to be consistent with the URL spec

  TabAtkins: So objections to changing the values and units to make
             invalid empty URL fail to resolve automatically?

  RESOLVED: Change the values and units to make invalid empty URL
            fail to resolve automatically

  plinss: Anything else on this?

media queries "not" is inconsistent
-----------------------------------

  <TabAtkins> http://lists.w3.org/Archives/Public/www-style/2014Oct/0111.html
  TabAtkins: The treatment of "not" for invalid is inconsistent.
             Mostly it's intended, but there's some legacy text that
             negates the enclosed behavior
  TabAtkins: There's examples in the e-mail above.
  TabAtkins: Simply, the old legacy media type if you put in invalid
             it treats the whole media query as invalid.
  TabAtkins: So foo and not-foo are invalid
  TabAtkins: In media conditions if you're negating features we
             wanted the ability to say:
  <TabAtkins> (min-width: 500px) or (foo: bar)
  TabAtkins: We wanted this to work if min-width was right, no
             matter of what the result of foo: bar.
  TabAtkins: So we have production to handle things we expect in the
             future as valid but false.
  florian: So if you're doing a prefix thing and you're doing
           "(-webkit-foo: …) or (foo: …) or (-moz-foo: …)" only one
           will match
  TabAtkins: So we have if it's not foo: bar it becomes true.
             Unknown are true at the most local level.

  TabAtkins: The problem is we have MQ3 text that says unrecognized
             media features makes the whole thing false.
  TabAtkins: The problem is back in the day before MQ4 you could
             only use and. There was no support for "or" and "not".
  TabAtkins: At that point making one thing locally false and the
             whole thing being false was identical. That's no longer
             true and I think we need to remove that for MQ4
  TabAtkins: Allow unrecognized to just be false locally and
             preserve the boolean response.
  florian: I think that's what is the original intent, and we just
           accidentally failed to make it work. I'm for it.
  TabAtkins: Yeah.

  plinss: Anyone else?

  RESOLVED: Remove the old text that negates the entire media query
            if an unrecognized media value or feature appears

  <TabAtkins> (min-width: 500px) or supports(foo) <== this was true
              before resolution
  <TabAtkins> (min-width: 500px) or (foo: bar) <== this was false
              before resolution

  plh: Do we have a test for that?
  TabAtkins: We don't.
  plh: It would be nice to have a test.
  TabAtkins: As we do the MQ4 test suite, we should test that as
             hard as we can.
  TabAtkins: We have the MQ3 suite, but not with these new features.
  plh: So are you saying I should write a test or there are bigger
       things?
  TabAtkins: Please, write a test.
  plinss: We almost never would say don't write a test.

Remove setPropertyValue and setPropertyPriority
------------------------------------------------

  plinss: zcorpan brought this up. Anyone want to talk?
  [silence]
  plinss: We can defer this.

CSS Snappoints
--------------

  plinss: Mozilla sent out a note asking for progress. Is anyone
          working on this?
  MaRakow: I tabled it since Google wasn't interested. It's good to
           hear Mozilla is interested. I can start work on the open
           issues.
  smfr: We're also interested in implementing snappoints.
  MaRakow: Do you agree with what was on the list?
  smfr: We'd like the repeat thing. So you have scrolling and
        snapping behavior and almost everything we've seen used
        constantly spaced snapping, so we'd like one line of CSS to
        add snapping.
  MaRakow: That's my thought too.

  smfr: hober sent some feedback in the past about auto-snapping at
        the end.
  MaRakow: I'll double check on that. I think I got all the feedback
           into the spec.
  smfr: Thanks.

  smfr: webkit does have an implementation, by the way.
  MaRakow: Where can I try that?
  smfr: If you download the webkit nightly on a mac.
  MaRakow: Okay.

  plinss: Looks like we're ready for progress. Do you need help?
  MaRakow: We've got a good list. One question is a number of people
           were asking about new features like snap areas. Are
           people still looking for that area, or do they want to
           lock down the basics of snap points?
  fantasai: I'd like to take a look because I don't quite remember.
  MaRakow: Okay.
  smfr: Apple would just like the simplest set of features. Looking
        at advanced features is fine, but we'd like something solid.
  MaRakow: Okay.

Sizing of floated ::first-letter
--------------------------------

  florian: We resolved on this two weeks ago with a change of
           behavior.
  <florian> http://dev.w3.org/csswg/css-pseudo/
  florian: We don't have a clear spec as to where this should go.
           Selectors 4 doesn't define this because this was expected
           to go into css-pseudo (linked above), but that's just
           unofficial.
  florian: So we should either pull that stuff back into Selectors 4
           or we should publish pseudo officially.

  fantasai: For pseudo elements there was a spec from Adobe with a
            bunch of new features without consensus.
  florian: That's what I linked above.
  fantasai: I think if we just had the level 3 stuff but better
            defined that's easier to publish. Or we can split the
            pseudos into the places they most relate.
  fantasai: I guess the question is do we want to keep pseudos
            together in one spec or should we split them and put
            them with the formatting systems they interact with?
  florian: If we want it to be in one spec, it needs an editor.
  florian: That shouldn't be the only criteria.

  dauwhe: A lot of stuff in pseudo does talk about details of
          first-letter stuff. Some examples make me cringe. There
          may be some utility in moving that out.
  astearns: I'm not sure if there's utility from putting that stuff
            together.

  fantasai: We still need to define what the first-letter pseudo
            contains.
  florian: This replaces selectors 3 so there's no spec to define it.
  fantasai: Except the pseudo.
  florian: It says it replaces it and the pseudos are defined
           elsewhere.
  florian: We can just remove these things and publish and that's
           what I linked above.
  dauwhe: astearns are you okay to remove multiple pseudos?
  astearns: Yep. I'd be happier if TabAtkins was an editor and do it.

  florian: So we have multiple resolutions. First, if the WG accepts
           first editor's draft for pseudo and than we add TabAtkins
           as an editor?
  plinss: I think that's the proposal.
  plinss: I think we need to add TabAtkins as an editor, remove
          anything not in selectors 3, and then publish.
  plinss: Objections?
  fantasai: Sounds good to me.
  dauwhe: Good to me.

  RESOLVED: Accept pseudo elements 4 as an official ED, add
            TabAtkins as an editor, and remove the bits that aren't
            in selectors 3

  plinss: That's the end of my agenda
  plinss: Anything else?
  plinss: Alright, everyone gets an extra 20 min

TPAC
----

  plinss: TPAC registration closes today!
  fantasai: One thing from me...Flexbox is in LC and the deadline is
            before TPAC. The goal is we process comments during TPAC
            and publish CR shortly after. We want feedback on main-
            size flex-basis auto-magic. That's all in the draft.
  fantasai: Please plan your research to be able to discuss it at
            TPAC.

  plinss: Thanks everyone

Received on Thursday, 9 October 2014 00:16:51 UTC