- 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