- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 8 Oct 2014 20:16:24 -0400
- To: www-style@w3.org
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