- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 18 Feb 2020 19:20:58 -0500
- To: www-style@w3.org
========================================= These are the official CSSWG minutes. Unless you're correcting the minutes, Please respond by starting a new thread with an appropriate subject line. ========================================= CSS Fonts --------- - RESOLVED: We are going to create keywords for unicode ranges (Issue #4573: Add ISO 15924 script codes to unicode-range) - The group will reach out to clreq to determine if kaiti should map to cursive. - Need to document some criteria for what typographic conventions merit a separate generic font family. One proposed "sufficient but not necessary" criteria was, do typographers in typical publications use distinctions between different these groups of fonts for semantic purposes? CSS Color --------- - RESOLVED: Move serialization [of <color> component values] into color-4 (Issue #982: Overlap between the definition of resolving color values and serializing <color> component values) - RESOLVED: color() functions, if they have a choice between percentage and number, they should use number (Issue #480: Serializing color() values) - RESOLVED: The `color(lab ...)` function, like the rest of the color() values, are in the 0-1 (or 0% - 100%) range. And they serialize the same as other color() values (as a 0-1 number) (Issue #480) <dialog> Positioning -------------------- - RESOLVED: Define dialog positioning in CSS terms, probably in css-position, with aim of replacing HTML's one-off description (Issue #4645: <dialog> positioning) - RESOLVED: Define dialog in terms of top layer and a snapshotted abspos position and alignment property for centering (Issue #4645) ===== FULL MINUTES BELOW ====== Agenda: https://wiki.csswg.org/planning/galicia-2020 Scribe: stantonm CSS Fonts ========= Add ISO 15924 script codes to unicode-range ------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/4573 myles: unicode-range takes bunch of code-points myles: Bad for a couple reasons, lots of numbers and not clear what they mean myles: also when adding some like emoji, you can list all unicode points - but it changes over time myles: Proposal to add keyword that lets the browsers define the code points florian: What are the keywords? myles: Issue says use keywords from ISO hober: We shouldn't define these things, reference something in unicode myles: Different languages use some common code points myles: keywords shouldn't be a partition, there will be overlaps myles: Space character will be in most of them fantasai: Two factors, script extensions list - some of characters are assigned to common script because they belong to more than one (but a limited set) of scripts. fantasai: we should be looking up script extensions, which tracks these fantasai: Other case is super common things - numbers, space, etc fantasai: A lot of things assigned to common script fantasai: probably makes sense to include common by default, but have opt out myles: We should resolve that we would like keywords, but not resolve on the actual keywords fantasai: We should rely on ISO faceless2: Rely on existing registry astearns: Should we have everything in the registry heycam: Do the names in the registry match normal css conventions? TabAtkins: Looks like no? fantasai: Should be a list of keywords 4 chars long <faceless2> https://www.unicode.org/Public/12.1.0/ucd/Scripts.txt <faceless2> example values : "Hebrew", "Devanagari", "Common" <astearns> `Zsye 993: Emoji` TabAtkins: If we're confident they are 4 letters, we can take directly fantasai: Think that should be fine, they need to maintain ASCII compat myles: We may get it wrong, can we tentatively resolve to try something out first florian: Go with 4 letter name of long name? or not deciding faceless2: Where did four letter name come from? florian: Long name has hyphens, 4 letter is defined somewhere else <dbaron> The 4 letter script codes are always letters and come from ISO15924: https://tools.ietf.org/html/rfc5646#section-2.2.3 TabAtkins: Casing shouldn't be important astearns: Leave it to the fonts editors to define what keywords we pull, don't need to resolve on that now myles: I'll also contact unicode jfkthame: Should there also be exclusion values? hober: If you could exclude a range, you could exclude common range myles: Be careful we don't turn this into a full language chris: Even if you do a good job, when unicode adds new values you may unintentionally exclude things chris: shift burden of defining onto external body RESOLVED: We are going to create keywords for unicode ranges <dbaron> also see https://unicode.org/iso15924/iso15924-codes.html <dbaron> "Zsye" is for Emoji, I think :-/ <dbaron> I think that's a little unfortunate. The Cursive = Chinese Kaiti equivalent -------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/4606 chris: First had these thoughts in CSS2, said cursive matched Cyrillic chris: How similar is kaiti to cursive? chris: Would like to see more comments from people who read Chinese myles: Can we ask i18n? chris: We should reference clreq fantasai: Usage of kaiti is similar to how English uses italics, not really cursive fantasai: Switching to cursive Latin font in middle of kaiti feels inappropriate heycam: See kaiti in children's books fantasai: Something like comic sans fantasai: not fully connected writing florian: Mapping English words like cursive doesn't always make sense in other language florian: inconsistent mapping chris: We don't provide typography for free, better to use font-family name chris: If you want something specific say something specific fantasai: High-level switching can be nice, distinguish paragraphs fantasai: Think we do need some kind of syntax florian: Should not map all keywords we have to other language florian: How far do we need to go? not sure astearns: We should ask clreq for this issue florian: What do we want to ask astearns: Do we need a keyword for kaiti, or can it map to existing keywords chris: Authors followed spec in good faith, browser implementors may need to back things out if we change myles: Valuable for us to have criteria on when to add new generic font keywords astearns: Open page on wiki for requirements of new keywords dbaron: It's useful to have that in the spec, fine to have non-normative explaining why the spec is this way hober: It lets people know how to change it if they see it in spec astearns: Put in wiki as scratch space <astearns> some variable fonts are both serif *and* san-serif dbaron: Can we extract metadata from fonts to help derive these keywords myles: Most existing generic font families fail that test jfkthame: In theory PANOSE should work, but in practice usually not there myles: Some criteria for naming, needs to map to more than just one font file myles: useful for installed fonts, OS's need to have installed fonts that match myles: Other criteria is that at least two OS support a font for that generic chris: Not always helpful in underrepresented languages astearns: But we already resolved to do work on that front fantasai: So then it's "with appropriate language pack installed" <fantasai> for some appropriate definition of language pack myles: Computers don't know, browser dev needs to manually type in list fantasai: Threshold should be whether typographers in typical publications are using distinctions between different groups of fonts for semantic purposes fantasai: example is italic vs normal vs bold in latin [e.g. normal paragraph text vs emphasis vs code] fantasai: sans-serif, serif, monospace makes a semantic distinction dbaron: Does serif/sans-serif meet that criteria hober: Good to come up with criteria, stuck with the ones we already have hober: new criteria should just work going forward, may not fit existing perfectly fantasai: There are stylistic distinctions sometimes, but can also be semantic in many others florian: Criteria is useful for prioritizing, but hard to say yes/no fantasai: If we meet the criteria, should add; if we don't, we may add <fantasai> it's a sufficient but not necessary criteria CSS Color ========= <color> serialization ------------------- github: https://github.com/w3c/csswg-drafts/issues/982 chris: CSS object model has not clear text about how to construct these color strings chris: color-4 should obsolete that part of the model chris: Do people agree? or do we think it needs serialization chris: Even if you have rgb with percentage, some bits get thrown away chris: Should it be in color-4 or OM emilio: As long as its well defined I don't care TabAtkins: Prefer color spec leaverou: Remove it from CSS OM and just point to color-4 florian: Agree, color-4 now has appropriate information to represent that spec RESOLVED: Move serialization into color-4 fantasai: Before we remove from OM should we publish it TabAtkins: Publish both after the move Serializing color() values -------------------------- github: https://github.com/w3c/csswg-drafts/issues/480 chris: Dean raised how does the color function get serialized chris: What's a good serialization, for all the new ones they need to be floats chris: any problems with that in OM TabAtkins: If it's not int it will serialize property, as long as data model underneath is number chris: For color you can use 0-1, or 0-100% chris: 0-1 was simpler emilio: Consistent with alpha RESOLVED: color() functions, if they have a choice between percentage and number, they should use number chris: Lightness is a percent, how do we handle that specific one TabAtkins: Percentage and number equivalence is defined as 0-1 equals 0-100% TabAtkins: so we can't just accept number TabAtkins: In the color function, just follow the rules - which is 0-1 fantasai: Agree with tab florian: For match function we take 0-100? christ: Eventually caved to just take percent TabAtkins: Could be this one color space takes 0-400, so doesn't matter chris: Some people use equipment that gives back L in 0 to 100 range and no percent fantasai: Adding the percent sign makes sense TabAtkins: Don't do the weird thing with lab and percentages (?) chris: Did it for rgb, so we argued it might make sense for lab chris: It's longer so not being used as much <AmeliaBR> We already have RGB functions where percentages map to 0-255 in integers. Because that's the convention for that data type. If integer 0-100 is the convention for lab. <AmeliaBR> ... maybe makes sense to follow. <fantasai> in the color() function? <AmeliaBR> Ummm… I don't know which syntaxes are allowed there. <TabAtkins> Proposed Resolution: the `color(lab ...)` function, like the rest of the color() values, are in the 0-1 (or 0% - 100%) range. And they serialize the same as other color() values (as a 0-1 number). RESOLVED: The `color(lab ...)` function, like the rest of the color() values, are in the 0-1 (or 0% - 100%) range. And they serialize the same as other color() values (as a 0-1 number). <break> <dialog> Positioning ==================== scribe: fantasai github: https://github.com/w3c/csswg-drafts/issues/4645 TabAtkins: Dialog layout description, two modes TabAtkins: 2nd one is a very long run-on sentence that's weird and not described in CSS TabAtkins: Behavior is useful, but unfortunate not in CSS TabAtkins: So a few things to do TabAtkins: First question, is this worth trying to put into CSS? TabAtkins: Next, quick description of what it is and what might be involved, to get an idea of how it would work TabAtkins: Thoughts on whether to describe in CSS, or treat as a special one-off case in HTML <AmeliaBR> Define in CSS please! florian: In general, think it's better to do in CSS florian: but if extremely complicated * low value, maybe not smfr: Authors might want to use the same type of positioning for their own fake dialogs smfr: so better to have in CSS * tantek has mixed feelings about this <AmeliaBR> Defining in CSS also makes it easier to modify / override with CSS (e.g., by media queries, interactions with other CSS). TabAtkins: Aim to get a resolution to add this to CSS, does anyone object to me putting this into some spec, probably css-position? TabAtkins: I'm taking the silence as assent tantek: Any security considerations wrt lowering barriers to making fake dialogs? TabAtkins: Can do in JS already TabAtkins: So can we take a resolution to that? RESOLVED: Define dialog positioning in CSS terms, probably in css-position, with aim of replacing HTML's one-off description fantasai: ... TabAtkins: ... emilio: It's a stateful position, because you don't want to reposition the dialog when you scroll or relayout TabAtkins: Here's the basic description- TabAtkins: Ignoring stacking context aspect TabAtkins: except for positioning bit TabAtkins: it's basically abspos TabAtkins: where we figure out the offset to apply when it first comes into existence TabAtkins: such that it's safe-centered into viewport TabAtkins: From that point on, it's just abspos -- you scroll the page, it scrolls off TabAtkins: If you dismiss the dialog and regenerate, it will recalculate its position TabAtkins: Interesting question is when do we clock this point in time? TabAtkins: Answer should be when animation starts iank: Another way to define is in the DOM layer iank: for the DIALOG element it could query what the layout is and set the top directly via CSS TabAtkins: Essentially built-in JS iank: We do this for other things iank: It's not great, but might be simpler <tantek> is it not fixedpos? huh <TabAtkins> nope, it scrolls if you scroll the page [so you can see content below the fold, if it's a long dialog] Scribe: heycam emilio: My objection wrt when boxes are created is that engines create boxes at different times emilio: When you change the display value, Blink will reposition, because it destroys the box and loses the state TabAtkins: If you go from not having boxes to having boxes, you reposition. Having boxes to having boxes, you don't reposition TabAtkins: Ian's description was also quite good, smfr what do you think? fantasai: To describe Ian's suggestion, at the point the dialog is launched, the UA sets the top/bottom/left/right properties to match edges of the viewport and absposes the dialog fantasai: and then, we use the alignment properties to center it within that area fantasai: You don't have to calculate the centering fantasai: just use the inset properties to bring the abspos area to match the current viewport area when the dialog is launched smfr: Sounds like you're snapshotting the layout viewport fantasai: You're assigning abspos inset properties so that you're creating a box that overlaps exactly the fixedpos containing block smfr: Wondering if it should be defined in terms of the layout viewport somehow TabAtkins: The HTML spec does require recalculating the position if the viewport changes size TabAtkins: Guess that's still possible, it's just a ResizeObserver on the window smfr: Another question is if the user zooms. Same behavior as fixpos? fantasai: As abspos, if the user wants to zoom in to see the dialog they should be able to TabAtkins: Don't want fixpos magic. abspos with magic setting at a particular time fantasai: I think that this works and is simpler than creating a new magic model with timing implications fantasai: Question I have is, if you have a dialog that's inside one of these containing block trapping elements, how do you get this element to escape and become contained by the containing block TabAtkins: That's answered by top-layer TabAtkins: In this mode it's always kicked into that TabAtkins: Do need to specify top layer rendering fantasai: Putting something there changes stacking context and containing block? TabAtkins: Yes TabAtkins: abspos containing block becomes the root fantasai: How does that interact with transforms or contain layout? TabAtkins: Layout containment should still be fine with escaping TabAtkins: and transforms ,it changes its parent TabAtkins: It's no longer transformed iank: Yes. it's weird fantasai: So it sounds like what we're doing is defining a way to put something into the top layer, out of the box tree, into this parallel box tree (list) where the containing block is the size of the entire page TabAtkins: I think that's the right thing TabAtkins: Think it's the whole page heycam: Interactions with full screen? they'll both be in the top layer TabAtkins: We'll need to deal with that TabAtkins: separate but intersecting topics smfr: Top layers will stack up smfr: if you have full screen and dialog fantasai: What's the stacking order? smfr: Whichever's created first smfr: but we need to define that fantasai: It's not as much of a mess as fieldset/legend... :) iank: Painting wise this is more interesting smfr: Part of me wonders if we need to maintain compat with dialog layout. Is this sensible behavior in HTML? Or should we define something different smfr: Think only Chrome has shipped TabAtkins: I've used dialogs in personal projects and enjoyed it iank: Are we the only ones shipping it? TabAtkins: I think so iank: I would be up for potentially investigating what compat risk there is if there's a more sane model that we think we can ship iank: The compat thing will be the question iank: Simon what caused you to start investigating this? smfr: I was just looking at how the implementation would work in WebKit smfr: and I dug into the Blink code and found a function deep down smfr: in block layout smfr: Didn't want to do the same thing RESOLVED: Define dialog in terms of top layer and a snapshotted abspos position and alignment property for centering smfr: Can we also resolve on specifying top layer behavior in CSS somewhere? smfr: It needs to live along with paint order and z-index smfr: wherever CSS 2.2 Appendix E will go fantasai: probably CSS Position? smfr: or a new spec smfr: I feel like a paint order spec is probably necessary dbaron: I think we need a spec for a bunch of rendering stuff, including common terminology dbaron: If you remember the big table of horrible test cases for stacking contexts, etc., we need a spec to cover that fantasai: So new spec for the painting order dbaron: CSS Rendering Model or CSS Painting Model? <tantek> perhaps that could include hit-testing which is directly related to stacking order etc. <tantek> more than just painting, the stacking order affects hit-testing
Received on Wednesday, 19 February 2020 00:21:39 UTC