W3C home > Mailing lists > Public > www-style@w3.org > April 2019

[CSSWG] Minutes Telecon 2019-04-03 [css-easing] [css-env] [css-text]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 3 Apr 2019 22:16:38 -0400
Message-ID: <CADhPm3tdtF=b+aPypV5Bf6+woAeOkZobajEdwJxFTSfJavwrJw@mail.gmail.com>
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.
=========================================


Easing functions to CR
----------------------

  - RESOLVED: Ask to take Easing Functions to CR once these editorial
              changes [for Issue #3205] are made.

CSS Environments
----------------

  - The proposal to get document title using css env() (Issue #3685)
      met with skepticism from the working group. In order to proceed
      with this approach the group needed to see more evidence that
      this would solve most of the potential use cases either as is or
      as an enhancement to the original proposal or that there are
      other document properties that would want to have the same
      functionality as proposed for document title. Interested parties
      will continue to investigate the use cases.

High Contrast Spec
------------------

  - Rossen wrote up a proposal to bring the Edge high contrast
      behavior into CSS specifications. There was debate on where this
      work should go so the group will review it this week and then
      decide where this should be put in the official CSS repo.

CSS Text
--------

  - When looking into a new property for MathML a larger question was
      raised concerning if the stated design of text-transform when
      applied to something like a screen reader needed to change in
      order to align with current implementations (Issue #3775:
      text-transform's design, intent and reality resolution)
  - It was questioned if the difference is actually as large as the
      issue indicated since the text-transform is not changing the
      fundamental structure of the document and cannot be treated as a
      core part of the document since some view modes remove the CSS.
  - text-transform contains many possible values so there will be a
      need to either split this into more than one property or spec
      how the properties differ as there are different solutions per
      property.
  - Other groups will need to be brought into this conversation to
      ensure that the decision reached is correct for a wide audience.
      CSSAAM was specifically called out at a task force which should
      discuss this.
  - A possible way forward is to expose detail of transform and
      original content at the same time instead of only exposing the
      transformed content so that screen readers can make a smarter
      decision then they can today.
  - Discussion will continue on the issue.

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

Agenda: https://lists.w3.org/Archives/Public/www-style/2019Apr/0000.html

Present:
  Rossen Atanassov
  Amelia Bellamy-Royds
  Brian Birtles
  Oriol Brufau
  Elika Etemad
  Simon Fraser
  Dael Jackson
  Brian Kardell
  Peter Linss
  Myles Maxfield
  Cameron McCormack
  Ian Pouncey
  Fran├žois Remy
  Melanie Richards
  Florian Rivoal
  Alan Stearns
  Greg Whitworth

Regrets:
  Tab Atkins
  David Baron

Scribe: dael

  astearns: We should get started
  astearns: We will skip item #7 and add Rossen's addition after
            item #2
  <Rossen> Thank you!
  astearns: Anything else people would like to change?

Easing functions to CR
======================

  birtles: I don't have anything that needs to be added. Ready to go.
  astearns: No more edits?
  birtles: Not that I'm aware of
  astearns: This isn't the first time to CR so there's not much
            besides deciding to
  birtles: Good point

  <fantasai> only open issue is https://github.com/w3c/csswg-drafts/issues/3205
  <fantasai> which is editorial
  <fantasai> significantly editorial, but still editorial :)
  birtles: That's [the open issue] probably worth doing
  fantasai: Worth doing but not block CR. Nothing technically wrong
            with document and won't effect impl. Editorial that can be
            done during CR. We should signal this spec is done and
            people should impl and deploy
  astearns: Not concerned with review before this change?
  fantasai: This change is about making spec easier to reuse in area
            that need timing mapping but aren't animations and
            transitions so I don't think that will make a difference
            to implementations. I don't think it needs to prevent CR
  astearns: birtles what do you think? Change in first or CR update?
  birtles: Can I do the change today and get a resolution?
  fantasai: Sure. I just didn't want to wait for some indefinite years
  AmeliaBR: We're agreeing to change words timing function to easing
            function and relating edits? That's all you're changing?
  birtles: Yeah and all the descriptions that say these can be applied
           to animations to say things like animations
  florian: But it's a generalization of sentences, not a deep re-write
  birtles: Yep
  florian: Then I see no problem resolving before edits
  <Rossen> Ship it!

  astearns: Objections to Take Easing Functions to CR once these
            editorial changes are made?

  RESOLVED: Ask to take Easing Functions to CR once these editorial
            changes are made
  astearns: Thanks birtles to getting to those edits

CSS Environments
================

Getting access to the document title
------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3685

  astearns: This was introduced last week, discussion of scope and
            that it's not useful in all situations. What else did you
            want on this florian?
  florian: Not much to add, just cut by clock. I think it would be
           useful to be able to access doc title from env. tantek
           pointed out this is not powerful enough for general problem
  florian: The generic solution pretty much calls for regions, though.
           This is much simpler and solves some cases so I think it's
           good to do. I recognize it's not a full solution

  AmeliaBR: One thing is that CSS has a mechanism for what florian
            wants in GCPM module. That is a much more complex and
            nuanced system of pulling bits of text from a heading and
            reusing in other parts of layout.
  AmeliaBR: I don't know if there's any interest in getting that
            cleaned and into browsers or if we want the quick win
  florian: I think we should do this regardless. Other is slightly
           more powerful, but it's still plaintext only and only works
           in paged margin boxes so if you don't paginate you get
           nothing. So this is less expressive but more applicable and
           simpler
  florian: I was discussing in context of Viviostyle and there were
           cases to not invoke the whole complex process, just I want
           the title and put it there.
  florian: I don't think I wouldn't be pushing if we didn't have nth
           function. We have the mechanism so this is exposing a value
           through it

  Rossen: Main motivation is in paginated scenarios?
  florian: Commonly seen in paginated but this doesn't have to be
           restricted. With nth works everywhere. If you want
           something pagination-like you can invoke things like this
  Rossen: Just curious use cases
  florian: Same type of layout as paginated media but actual
           pagination with css level of page is one thing, but
           something that visually looks like pages is another. I'm
           aware of wanting to do things that look page-like is a use
           case

  fantasai: Concern is this is too simple for what's wanted. If we go
            in this direction we'll be too limited. Don't know how
            urgent this is. If it's not something we have to do really
            soon might be worth trying to sort out more generic that
            solves this class of problems rather then special casing
            this
  <bkardell> it seems like we have maybe a lot of things that are
             almost related to this
  florian: Don't think particularly urgent. In that sense okay with
           punting. More generic is way more complicated. I don't see
           this as trying to solve whole problem. If want to expose
           more through nth it seems reasonable.
  fantasai: If it would solve 80% use cases it's worth, but seems
            closer to 20% so I don't know it's worth introducing a new
            pattern if we're not planning to pursue patterns
  florian: I think for ebook this would solve most of the problems.
           Depends on how you say 100%
  fantasai: But they also want page number and chapter
  florian: But in ebooks, chapters are HTML files, so, it is
           sufficient for that case. It is simple

  bkardell: I'm interested in this use case. I feel like I would like
            to talk to florian a bit to understand more off call. If
            it only can give you the plain text would you not be able
            to achieve most by setting a custom prop for now? I think
            we said it's just plain text so the 20% of use cases
            wouldn't they be served equally as well with a css custom
            property?
  astearns: It's content duplication and you run the risk of out of
            sync. This is slightly better then duplicating in custom
            properties
  florian: ebook with 25 chapters if you use nth you pull from doc,
           custom prop you have it for each chapter
  bkardell: That's what I'd like to understand more. They're not input
            manually, they're built.
  bkardell: Would mean multiple rules
  astearns: Prob enough for now. Not hearing enough to pursue for now.
            Maybe if we saw use of custom properties for this could
            make better solution

  florian: I'm hearing sufficient skepticism we're punting
  AmeliaBR: florian worth looking if there are similar doc properties
            where worth a common mechanism. Doc URL or parts of URL
            might be similarly useful. Have permalink on a file. I
            haven't looked and it's a matter of looking at what people
            are actually using to insert into the generated content
  florian: We can think of a few more, but that's enough for the topic
           today. We can go offline

High contrast spec
==================
  link: http://htmlpreview.github.io/?https://github.com/atanassov/css-high-contrast/blob/master/Overview.html

  Rossen: I don't have a github issue for this
  Rossen: I had an action after the F2F to go and put what we had in
          an explainer and add more spec text to introduce high
          contrast feature as is defined and working inside of edge
          and IE
  Rossen: The pretty print of the HTML is linked above
  Rossen: Request is to move this out of my github and into CSSWG repo
          as one venue or pursuing this. Or identify parts of spec
          that will go to currently worked on specs. I can see a MQ go
          to MQ spec, cascade going to cascade. That's what I wanted
          to get from WG and figure out next steps

  Rossen: Not sure if anyone had a chance to review, it's fairly short
  fantasai: I haven't but TabAtkins and I plan to tomorrow. I can get
            review by next week
  Rossen: Sounds great. I just want to take it out of private repo and
          get it into CSS
  Rossen: I'm okay breaking this apart into appropriate specs or keep
          as one until it solidifies more and then break. Either is
          okay
  fantasai: Ultimately want all MQ to go int MQ5. High contrast props
            should go together, don't know spec
  <fantasai> there was a printer color adjust control as well that
             should go together with this
  Rossen: This is something...this is why I wanted to keep it as one
          spec to begin so it brings whole picture together in terms
          of what the high contrast feature does. Once this is better
          understood we can break apart into appropriate modules
  florian: Depends how many we want to break into. Mostly together
           makes sense. I'm interested in splitting MQ early because
           the whole thing is interaction between that MQ and others
           in that domain. I'd hate to go too far and it doesn't mesh
  Rossen: You suggesting break MQ out now and add to MQ5?
  florian: And the rest in the stand alone ED and work on that
  AmeliaBR: Looking at Rossen's draft there isn't a lot of the rest.
            Any problem with all into MQ5 for now and maybe we find a
            better place for the extra property later?
  Rossen: Not opposed
  fantasai: Makes sense. Not stay indefinitely but for current state
            of discussion makes sense to have a section that deals
            with color adjust stuff

  florian: Rossen do you want to be a coeditor of MQ5?
  Rossen: Sure

  astearns: Do we want to resolve to add this to MQ5 now or give a
            week for review?
  <fantasai> MQ is re-used outside of CSS, so definitely shouldn't
             stay there :) But fine to be there for a few months while
             we figure out where things should go
  <heycam> +1 to move it all into MQ5 for now
  Rossen: Comfortable with either. If people feel this is better in
          MQ5 and this is where we're going to go let's just go. We
          can always make changes
  fremy: Agree with Rossen. We can start to files issues against it
         which is better then filing issues when it's not official. If
         we all agree it's in MQ5 let's agree on it
  fantasai: I'd say wait a week. I can do a review and maybe we have
            clearer idea of what we want to assign
  fremy: I have issues I'd like to file but I don't know where
  fantasai: We do have a single repo so you can file and tag later

  Rossen: If it's okay with WG I cam move spec as-is right now knowing
          it's unofficial into CSS Repo. I'm attending blink-con next
          week during call so I'm not going to be present. I would be
          happier if people started shooting issues into a repo and
          tag against spec
  florian: Okay with that
  astearns: I'd rather not put it in repo as-is if going to put it
            into MQ. Rather open issues on repo and tag later. Just @
            Rossen and melanierichards

  <AmeliaBR> We also have another proposal for a "media-query
             adjacent" CSS property in `supported-color-schemes`,
             which should probably go in the same place as this
             high-contrast override property.

  florian: There's 2 parts in this to me. MQ and high-contrast-adjust.
           high-contrast-adjust is a pattern I think we'll see so it
           belongs. The new cascading border doesn't belong. It's got
           the backdrop in there?
  Rossen: It's not there. It's not currently expressed as a reachable
          entity through style layer. If you recall the discussion I
          did point out to be successful for impl. There was some
          interest this could apply to things like captions. In event
          that we believe this new feature should surface on CSS layer
          I can add the spec text. For now not exposed because can't
          be reached by author
  florian: That part just doesn't feel like it should be in MQ
  Rossen: Agree, totally different. Maybe it's B&B if anything

  astearns: Let's keep in Rossen's repo for now. Please review doc and
            open issues on our repo and we'll descide after a bit of
            review what we'll do

CSS Text
========

text-transform's design, intent and reality resolution
------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3775

  astearns: Wanted to have this introduced so can make a bit of
            progress before bringing in more people
  bkardell: I don't see where this was spec originally in the design,
            but at some point it became a stated thing we have talked
            about about the intent of text-transform and what it
            exposes to screen readers and why
  bkardell: Feel like I dropped the ball a bit on kana discussions
            because I know it wasn't reality and assumed other people
            did too. Some of the text stuff I don't feel I can comment
            so wasn't paying close attention
  bkardell: Opened a different issue requesting something that is
            inline with how screen readers work. That changes to how
            we have designed to not expose text to screen readers.
            It's come up that it does not match reality
  bkardell: AT and browsers have chosen universally to expose
            transform text. I'd like to consider that so that we can
            properly discuss the other issue
  bkardell: My position is that the ones that exist and in wide use
            are stated design principle is out of touch with reality.
            It's a conscious choice that's what users want. At a
            minimum our principle needs some finesse

  florian: The discussion is a bit long winded, I'll jump to where we
           are. I don't see the same contradiction as bkardell if we
           look a little deeper. Don't think it's interesting to
           debate what screen reader users what, the experts have
           said. Screen readers do not give access to raw doc, they
           present it. It's easier to include the transform. I don't
           think that makes semantics change
  florian: I don't think we could do that. There are places where we
           don't present CSS so we can't say that text-transforms are
           an intrinsic part of doc that can't be removed. If screen
           readers as one UA think best way to present is to apply the
           text-transform, great. But I don't think we can go from
           there to never not allow them to be applied. If you
           introduce a new text-transform old browsers won't know
  florian: I think we have to recognize that the doc is the doc and
           the text-transforms need to be allowed to apply. I think
           the claim that case transforms are desirable is credible,
           but I don't want to generalize to say all transforms always
           must be preserved. I think cjk and i18n transforms you want
           the other way.
  florian: I think we need to discuss transform by transforms, but
           can't say all must be preserved

  fantasai: I agree with florian that text-transform can't be
            intrinsic part of doc semantics. They were designed as a
            way to have this distinction partly. If we don't have them
            to different doc and visual rendering we'll have to find a
            way to do it.
  fantasai: Someone suggested creating a custom font, I don't want to
            get into that arms race
  fantasai: I'm not sure how deeply this was investigated in the past.
            I don't see anything in bugzilla. Chrome issues had people
            arguing on both sides. I don't know if this has been
            investigated deeply enough. We need to talk to the people
            we need to talk to and figure out what to do. It's
            possible the current situation is what fell out of
            original implementations, and screen readers just dealt
            with it but it's not ideal. If no discussion on Gecko it's
            probably what's convenient

  IanPouncey: Few points, to reiterate bkardell's point it seemed to
              those of us who work with screen readers that this was
              common knowledge, that's on us. For what florian said I
              think misconception about where problem lies. It's not
              screen readers doing transform, it's the browser and
              a11y tree exposing it
  IanPouncey: It's not screen reader doing anything in most modern
              browsers. Any of the ideas of a screen reader making a
              decision about what to present is problematic because
              you cannot reverse a transform to uppercase because you
              don't know what char were uppercase
  IanPouncey: Speculating on this, I wonder if there's a similar issue
              for content on the radar. I think there was an
              assumption when property introduced that it's not
              exposed to screen readers and it is now. I wonder if
              there's a similar problem there
  <fantasai> Point about delivering transformed text through AT
             meaning screenreaders can't access original text even if
             they want to is imho important

  Rossen: Way screen readers work is a long discussion. How text is
          represented also heavily depends on current platform support
          and AT consuming that information. nvbia on windows will
          have different characteristics to express richness of text
          compared to narrator using ui automation
  Rossen: One thing I know from interacting with the community and
          a11y wgs and impl a11y the thing I can tell you is a lot of
          people think of screen readers for the blind. It's part of
          the users but not all. Most people are those with low
          vision. They can see parts of the screen. So when you start
          producing disparity between rendered results and what screen
          reader represents it becomes confusing
  Rossen: Consider editing scenarios- most people will navigate text
          by character to check spelling. If at that time you have
          text-transform that caps for example for them to not know
          it's upper case will be confusing. Same reason why we map
          ital to em, lots of font features that map to a11y prop I
          don't see why this should be unique
  Rossen: Other thing I want to give a big shout out, CSSAAM would be
          ideal place to continue this discussion
  <fantasai> wrt checking spelling in editing environment... ideally
             you want to know what text you're actually typing, for
             when the text-transform goes away -- source text should
             be following standard capitalization rules, would be
             problematic if ::first-line { text-transform: uppercase;}
             led someone to type in all-caps when replacing one word
             with another in the first phrase of a para
  <fantasai> generally, editing text with text-transform turned on is
             going to be very confusing regardless...

  AmeliaBR: There's 2 aspects to the discussion. What should happen,
            how is best way to expose full information. Then specific
            practical issue in that we have recently added values of
            text-transform with some impl and this new prop for math
            variants
  AmeliaBR: By putting it all in text-transform it forces us to treat
            them the same for exposing before or after transform values
  AmeliaBR: Even if not complete agree on optimal for exposing case
            changes I'm trusting florian that exposing CJK
            typographical is a problematic situation from a11y.
  AmeliaBR: If mathML comes through it's very important to expose
            transformation.
  AmeliaBR: With these different semantic impacts it might be worth
            discussing if these should be split up, even if it's
            transform to long hands that could all reset by a
            shorthand but there is a text-transform case that's
            different then CJK text-transform. If we separate to
            different properties we can start talking semantics and
            what strange transformations happen
  AmeliaBR: Especially in terms of what's exposed to a11y, innerText,
            copy/paste APIs, lots of places where people use
            text-transform and if they're not all equal maybe use
            different properties
  <fantasai> reason to have separate longhands is needing them to
             cascade separately... if the only concern is what impacts
             they have, we can categorize within the spec

  florian: I am aware about difference IanPouncey mentioned between
           what screen readers do and what's in at. Idea is that text
           in AT would be end transformed text and have the original
           information so screen readers can make decision. In case of
           case transforms if every screen reader wants to do the same
           thing with it and the current AT does the transform already
           it will be uphill to un-transform. For case transforms if
           it's a standard today fine let's leave it
  florian: But that's what I want to Japanese which is keep
           untransformed text and keep information about transforms so
           that screen readers can add extra information if they want.
           The Math case I think is kind of related. I don't think we
           can rely on the transforms to change document semantics.
  florian: If we want to introduce a new semantic differences we have
           to introduce it in the document and that can impact the AT
           tree. We can't just change the font and claim it lets us
           introduce semantic differences that would change the
           meaning of the document. Upper case is useful but not
           changing doc meanings. If we want to introduce math it will
           fail in all cases

  astearns: To respond to AmeliaBR- I think the idea of separating
            properties is interesting but maybe not entirely
            necessary. If we want we can spec what happens to values
            or properties and they can differ.
  astearns: To respond to florian I think there is prob a fallback
            that can work for new math transforms. If you see support
            you get fractor, if you don't you do extra styling
  florian: And it disappears in reader modes
  astearns: Fair
  florian: If you want to style that's fine. Introducing fundamentally
           different semantics won't work.

  IanPouncey: Cautious +1 to expose detail of transform and original
              content. I can see if there's any appetite for that.
              Hopefully we can get idea if that's possible. Also
              acknowledging the prompt to add CSSAAM to this discussion

  AmeliaBR: Follow up on florian's concern about semantics in
            document. The request for math transforms is from MathML
            as a way to describe behavior of MathML attribute in a way
            that can be consistently impl. That is something where
            there is semantics in doc level but nice to be able to
            describe it. Maybe also use same effects in more
            decorative cases
  florian: Fair and useful so thing into a11y tree is the transformed
           and may be useful

  astearns: We're at time. The call bridge will stay open if people
            want to chat and then put the discussion in the issue
  astearns: Thank you all very much
Received on Thursday, 4 April 2019 02:17:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:53:13 UTC