- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 25 Apr 2018 16:41:06 +0000
- To: public-css-archive@w3.org
The Working Group just discussed `Should we add scientific notation to CSS 2.1?`, and agreed to the following resolutions:
* `RESOLVED: take 4.1, 4.2 and 4.4, change them to informative notes, and add notes to those sections + appendix G showing where the newer work is being done. Links to newer works are informative notes.`
<details><summary>The full IRC log of that discussion</summary>
<dael> Topic: Should we add scientific notation to CSS 2.1?<br>
<dael> github: https://github.com/w3c/csswg-drafts/issues/2542<br>
<dael> gsnedders: We accidently agreed to add scentific notification to CSS L2. Do we want to do that for real?<br>
<dael> florian: When did we agree?<br>
<dael> gsnedders: Agreed before the reset but after the rec. WE said we'd normatively reference CSS 3 syntax which added a new feature.<br>
<dael> florian: Is the CSS 3 syntax reference separate?<br>
<dael> gsnedders: Yes, next.<br>
<dael> gsnedders: Do we want to add a new feature to CSS 2?<br>
<ChrisL> I'm not sure it is a new feature, given it is not independently testable<br>
<dael> astearns: I think no. Anyone disagree?<br>
<dael> ChrisL: Disagree. THis is not a new feature, it's a new way of expressing something. You can't test the syntax without testing an app or a value. It's an internal spec matter.<br>
<dael> florian: Defining the syntax is, but pinting to the spec that does new things isn't new?<br>
<dael> ChrisL: We point to the syntax but the features are in the thing sin 2.1 We don't take advantage of the extra features. REasonable?<br>
<dael> florian: I think we need to overflow into the other agenda topic to answer.<br>
<dael> gsnedders: Relevent thing is the definition of number, right?<br>
<dael> fantasai: There was an issue around URLs tto, right?<br>
<dael> gsnedders: We have errata for that.<br>
<dael> florian: gsnedders your question is not jsut do we want to introduce a new feature but also do we want to introduce a new feature independantly of if we reference the new syntax.<br>
<dael> florian: I think the only reason is if we see value and cannot reference syntax 3 without adding it.<br>
<dael> ChrisL: Is this change [missed] or is it an actual change where you support both?<br>
<dael> gsnedders: You can support both it's new syntax for the additiona number<br>
<tantek> q?<br>
<dael> ChrisL: So jsut the subset in 2.1<br>
<dael> TabAtkins: We could subset css 3 syntax but that's a bag of worms where to do correctly is substanital effort with no benefit. No one is impl css2.1. What is wrong with jsut normatively undefining css syntax for 2.1<br>
<tantek> q+<br>
<dael> florian: gsnedders wants to discuss possible scientific notation before discussing the link to syntax.<br>
<tantek> q?<br>
<dael> TabAtkins: We either undefine it or we link to Syntax. Those are only 2 options besides doing a lot of work to carve out a subset of what matches in css 2.1.<br>
<astearns> ack tantek<br>
<dael> tantek: I think there's a number of difficult options. I'm not convinced of any one and trying to understand trade offs. For CSS 2 work we have the mos timportant thing gsnedders and I are trying to do is keep the edits rolling in and go through CR/REC alternating process. In my opinion that's the primary driver of where we try and nudge decisions.<br>
<florian> q+<br>
<dael> tantek: Ideally we'd like to not introduce any new features. Even if it's inconvenient I'd like to see us do the worth rather then comprimise on that since we promised to ourselves and the community no new features. THat's my preference.<br>
<dael> astearns: I suggest we table scentific notation and go straight to the first topic.<br>
<dael> tantek: I'm concerned we're ducking the hard question of not adding new features. That's a design principle where as what reference we make is different<br>
<dael> florian: I agree with tantek we should stick to the process, but I don't htink that means we have to subset syntax 3. For this section I think I'm with TabAtkins and we should gut out the section that defines syntax and replace it with a note that says previous versions tried to do syntax, was proved incorrect, and we informatively reference the known better work in Syntax. Recognize we had a definition, it wasn't good, and here's what we have that's better.<br>
<astearns> ack florian<br>
<dael> TabAtkins: florian's suggested wording sounds perfect.<br>
<ChrisL> s/Is this change [missed] or is it an actual change where you support both?/Is this a true superset or an incompatible change? Is it possible to support both?/<br>
<dael> fantasai: My concern is it makes the spec mostly non-sensical.<br>
<dbaron> I think one could also add to the wording a note that the new module has a new feature: support for scientific notation.<br>
<tantek> so we can't actually do that without going back to WD, because technically it's normative feature *removal*<br>
<dael> fantasai: I'm not saying we need to keep grammar the way it is, but things like this is how you parse css in generla makes the rest of the spec make sense.<br>
<tantek> q+<br>
<dael> florian: We still point to syntax non-narmative to there's sense.<br>
<dael> TabAtkins: No one is adhereing to CSS2, we can jsut point non-normatively to where the definitions are.<br>
<dael> florian: Alternatively we keep the old section, put a note saying this is incorrect and put the rest as suggested. So if you're trying to make internal sense of the spec you don't need ot go to another. I don't think that's more useful the just the note.<br>
<gsnedders> q+<br>
<dael> fantasai: We'll have notes in all sections pointing to new sections. Reason we're stuck is an inconsistancy between L2 and L3 that means L3 impl is non-conformat to L2.<br>
<dael> TabAtkins: Yep, but we don't care about L2 impl. No on impl 2.1 at L2.<br>
<astearns> ack tantek<br>
<ChrisL> agree with Tab<br>
<dael> tantek: THe first suggestion to remove the syntax section for CSS 2 and replace with an informative reference to CSS 3 is untenitable because that's a normative feature remove and we can't do that because we're not going back to WD as per the plan we agreed to.<br>
<ChrisL> q+ to say we can totally remove features<br>
<florian> it is not a feature removal, we're not saying that CSS2 should not have a syntax, just saying that that syntax is undefined.<br>
<dael> tantek: I understand and accept the issue that CSS 2 syntax is not something we want people to impl. I don't think there's debate on that guidance. We're debating how to provide the guidance so that's it's clear to webdev and let sus iteratie on 3.<br>
<dael> astearns: I think your process point...is that because syntax is not marked as at risk?<br>
<dael> tantek: Syntax section, nothing in css 2 is marked at risk.<br>
<ChrisL> q?<br>
<dael> astearns: We remove nromative features, it's just usually that they're at risk.<br>
<dael> florian: I disgree this is feature remval. We're normatively undermining it<br>
<dael> tantek: Same thing.<br>
<dael> florian: It's not.<br>
<tantek> q+<br>
<astearns> ack gsnedders<br>
<fantasai> q+<br>
<tantek> removing something normatively removes it from IP as well<br>
<dael> gsnedders: My understanding os changes in syntax 3 are that mostly they relate to error handling. If we simply undefine the error handling wuld that work?<br>
<fantasai> gsnedders++<br>
<tantek> from a process perspective, removing or undefining it normatively is a removal of an *essential feature*<br>
<dael> TabAtkins: Let's see. Only positive feature is sci notation. Rest is error handling...yeah...normatively no longer have U range token. Yes, it's technically right. But you cannot impl error handling correctly as desc in 2.1<br>
<dael> fantasai: Error handling is a separate process and go look at this doc, then.<br>
<dael> TabAtkins: YOu can't impl with anything remotely like what looks in spec.<br>
<dael> florian: If you take it as a list of things that are correct the grammar is fine. You can use it for a validator<br>
<astearns> ack ChrisL<br>
<Zakim> ChrisL, you wanted to say we can totally remove features<br>
<dael> TabAtkins: How to validate? Nothing is defined in terms of it.<br>
<fantasai> TabAtkins, CSS2.1 stuff is defined in terms of it.<br>
<dael> ChrisL: Normally when pub updated REC it's edited rec and you don't go to WD. I think we can change things and mark things at risk and later remove. I also remain unconvinced that this is a feature, it's just how the syntax is expressed.<br>
<dael> TabAtkins: Agree.<br>
<gsnedders> q?<br>
<dbaron> I'd note that you can't go directly from REC->WD, but you can go REC->CR->WD. I think it's a bug in the process, though. (And I filed it.)<br>
<tantek> q-<br>
<tantek> q+<br>
<dael> astearns: As you spoke I was thinking this is something we'll have to deal with in the future for CSS 2. Coming up with a proper way to remove something from CSS 2 to point at a more accurate version is something we'll have to deal with generally<br>
<dael> gsnedders: I don't think other cases will be as bad as this. Things like properties we can just say L2 accepts these properties, see L3 for definition.<br>
<tantek> dbaron huh? pretty sure you have to go REC->WD per current process with new features (and I think for removed features too - checking now)<br>
<dael> florian: We can defer to L3 as REC.<br>
<astearns> ack fantasai<br>
<gsnedders> tantek: Process doesn't say, just for "new features"<br>
<dbaron> tantek, the process for revising a REC doesn't allow transitions other than REC->REC, REC->PR, or REC->CR, IIRC<br>
<dael> fantasai: My preference would be not to removet he section because it's a gaping hole. WE can remove error handling and we can add a reference to CSS 3 and we can add a statement at the top saying you can be conformat by impl here or L3. But ripping out the whole section I'm not comfortable. Internally CSS2 is defined in terms with its own grammar.<br>
<gsnedders> dbaron: https://www.w3.org/2018/Process-20180201/#rec-modify<br>
<gsnedders> dbaron: it's REC->REC, REC->CR, or REC->FPWD<br>
<tantek> dbaron, gsnedders is right - see flow chart<br>
<dael> fantasai: In that error handling we can say this is not correct, there is error handling and it means these things and the details are in L3, but it leaves us some overall syntax. THen we also have a reference for if you want to impl a parser go look overthere.<br>
<tantek> REC -> substantive changes? -> yes -> new features? -> yes -> FPWD<br>
<dael> florian: You don't want to break internal links?<br>
<dael> TabAtkins: Semantic links.<br>
<dael> florian: Sure.<br>
<tantek> looks like we can technically skip WD for *removing* features<br>
<dael> TabAtkins: My challange to that is what's better? A spec that points to a broken incorrect issue or a spec that is hand wavy. No one prefers to pointin to a broken thing.<br>
<dbaron> tantek, gsnedders: on the other hand, see the "next steps" in https://w3c.github.io/w3process/#rec-publication<br>
<dael> florian: Entry point of Syntax and SS 2 grammar are they the same?<br>
<dael> TabAtkins: THat concept isn't in CSS 2.<br>
<tantek> so now I'm ok with first Florian proposal, turning current section informative (thus normatively undefining), and adding informative reference to CSS3 Syntax<br>
<dael> florian: Terms CSS 2 uses other than gramamr still need to make sense. Nneed to understand what talking about.<br>
<gsnedders> dbaron: yes, I think REC->FPWD is expected to be a new REC-track document<br>
<dael> TabAtkins: IN terms of property we use the same terms. CSS2 uses a token sceme, but it's the same terminals.<br>
<dbaron> gsnedders, yes, that's what the last sentence of https://w3c.github.io/w3process/#revised-rec says<br>
<tantek> dbaron, looks like those "next steps" are not comprehensive, good catch. please cc me on the issue you filed on the process per that section<br>
<dael> fantasai: I'm suggesting the hand wavy thing isn't a giant gaping hole. We take that section, the error handling is where the problems and that small section can be turned into something more hand wavy and let's say it's less tight but have the rest of the section in tackt.<br>
<dael> TabAtkins: You have to go read other things. You can't read that grammar and impl CSS.<br>
<dael> fantasai: I'm not necessarily a impl!<br>
<astearns> ack tantek<br>
<tantek> q?<br>
<dael> TabAtkins: If you're not impl you're not looking at tokenization<br>
<dbaron> tantek, my issue was https://github.com/w3c/w3process/issues/103<br>
<ChrisL> q+ yes, because removal has no patent implcations<br>
<fantasai> TabAtkins, afaict you're not asking to remove tokenization, you're asking to remove all of Chapter 4<br>
<dael> tantek: I double checked the process. It looks like if we add features we have to go to WD, but not for removing features. Removing a new CR was sufficient. It lets us mark the whole CSS2 section as informative and then add informative reference to CSS 3 to give impl guidance. So welcome to syntax and if you're impl you have to go here. Remaining text is informative because it's out of date.<br>
<ChrisL> that would work for me!<br>
<gsnedders> fantasai, tantek: and presumably Appendix G<br>
<gsnedders> * TabAtkins<br>
<dbaron> tantek, And the "go to FPWD" option isn't, I believe, part of the Edited/Amended Recommendation process -- it seems to be for a new recommendation<br>
<dael> tantek: I think we can do that and continue with our work mode. Assuming florian and TabAtkins are good with that, fantasai does that sound good to you?<br>
<dael> florian: My initial proposal was gut the section, but I updated to do exactly what you said.<br>
<dael> TabAtkins: I'm okay if it's there if it's in some big colored box to show it's wrong.<br>
<dael> fantasai: Section?<br>
<dael> TabAtkins: Appendix G grammar. And a chapter that defined tokenization.<br>
<dael> gsnedders: Chapter 4.1 and 4.2<br>
<dael> gsnedders: Values section I think we still want.<br>
<dael> tantek: I think not.<br>
<dael> gsnedders: 4.3 values is replaced by values & units. So it's just 4.1, 4.2 and 4.4<br>
<dael> florian: And appendix G<br>
<dael> gsnedders: Yes.<br>
<dael> florian: Turn all of that into notes and add an intro note that it's for reference but known as not fully correct.<br>
<dael> fantasai: Why appendix G? I udnerstand the 4.x<br>
<dael> TabAtkins: It's a big set of grammar defined in terms of tokenization.<br>
<dael> fantasai: It's not error handling It's a valid CSS2 doc conforms to this.<br>
<dael> TabAtkins: There are some that don't because changes to CSS2 that's not backwards compat.<br>
<dael> fantasai: Example?<br>
<tantek> q?<br>
<dael> TabAtkins: URL syntax changed. You can conform to CSS grammar...<br>
<dael> fantasai: Exmpale of URL that's valid now and wasn't before.<br>
<tantek> "This appendix is non-normative. "<br>
<dael> florian: Appendix G states it's non-normative but section 4 refers to appendix G as normative.<br>
<dael> gsnedders: Yes, 4.1<br>
<dael> florian: [reads]<br>
<dael> tantek: Assuming we make 4.1 informative that becomes informative and it's fixed. We don't have to touch G.<br>
<dael> florian: Just adding a note on top is nice to do.<br>
<dael> TabAtkins: Yes, I'd recommend a note.<br>
<fantasai> +1 to note<br>
<dael> gsnedders: If we believe G is capricisious we shoudl remove<br>
<dael> astearns: Prop is take 4.1, 4.2 and 4.4, change them to informative notes, and add notes to those sections + appendix G showing where the newer work is being done. Those are informative notes.<br>
<dael> florian: Agree.<br>
<dael> TabAtkins: Fine with that<br>
<dael> astearns: Objections?<br>
<ChrisL> fine by me<br>
<dael> tantek: Clarify that references to CSS 3 syntax are informative and I"m good.<br>
<dael> astearns: Yes, that's the last clause. "Those" being link to newer work.<br>
<dael> fantasai: WE might want to tweak intro text in chapter 4.<br>
<dael> tantek: That's editoral.<br>
<dael> fantasai: I still want an example<br>
<dael> TabAtkins: DOn't have one off the top of my head.<br>
<dael> astearns: Given you wanted the example as to why we want to change G and we're not do you need it?<br>
<gsnedders> fantasai: http://w3c-test.org/css/CSS2/syntax/uri-013.xht<br>
<dael> fantasai: Not to resolve. Want the example.<br>
<fantasai> s/Want/Still/<br>
<dael> astearns: Obj?<br>
<fantasai> s/example/example though/<br>
<gsnedders> fantasai: that passes per 2.1 and fails per Syntax, AFAIK<br>
<fantasai> gsnedders, that's error-handling<br>
<gsnedders> fantasai: I haven't looked at that test in a long while :)<br>
<fantasai> gsnedders, it's not supposed to be a valid document.<br>
<TabAtkins> Example that fails 2.1 and passes Syntax: url("foo.txt" more-tokens-here)<br>
<dael> github: https://github.com/w3c/csswg-drafts/issues/2224<br>
<dael> RESOLVED: take 4.1, 4.2 and 4.4, change them to informative notes, and add notes to those sections + appendix G showing where the newer work is being done. Links to newer works are informative notes.<br>
<tantek> 🎉<br>
<fantasai> TabAtkins, that's invalid in CSS2 regardless<br>
<fantasai> TabAtkins, it's another error-handlign example<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2224#issuecomment-384353286 using your GitHub account
Received on Wednesday, 25 April 2018 16:41:12 UTC