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

[CSSWG] Minutes Fukuoka F2F 2019-09-16 Part IV: Shapes, Sunsetting the fxtf-drafts repo, CSS Lists, CSS Text 3, CSS Size Adjust [css-shapes] [css-lists] [css-text-3] [css-size-adjust]

From: Dael Jackson <daelcss@gmail.com>
Date: Fri, 4 Oct 2019 18:52:05 -0400
Message-ID: <CADhPm3voW4KPnp5a4wRwwxBkJLS4Xo7drL9xqafz+h5ynNCMdQ@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.
=========================================


Shapes
------

  - RESOLVED: Move path() down to Shapes 1, adding it to
              <basic-shape>. (Issue #4270: Define path() in Shapes 1
              or 2)
  - RESOLVED: Impls can ship clip-path:path() (Issue #4271: Is it okay
              to ship clip-path:path())

Sunsetting the fxtf-drafts repo
-------------------------------

  - TabAtkins offered to do the work to sunset the fxtf-drafts repo.

CSS Lists
---------

  - There wasn't a lot of interest in making changes to the counter-
      reset rule (#4244: Should list-item counter reset rule be in a
      UA stylesheet?) since doing so would require magic that either
      the authors couldn't change or would require another property to
      expose author control.

CSS Text 3
----------

  - Native Korean speakers will be consulted to see if an existing
      property would work to address the use case in issue #4286
      (word-break:keep-all and overflow) or if a new property is
      needed.

  - RESOLVED: Trailing "other-separator spaces" will hang, accepting
              Florian's PR (Issue #4180: How to handle leading
              ideographic space sequences)

CSS Size Adjust
---------------

  - RESOLVED: Add Myles as co-editor to CSS Size Adjust.
  - RESOLVED: Specify text-size-adjust more fully.

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

Agenda: https://wiki.csswg.org/planning/tpac-2019#agenda

Scribe: TabAktins

Shapes
======

Define path() in Shapes 1 or 2
------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/4270

  astearns: A number of specs are using <basic-shape>, which has
            several functions in Shapes 1, but not path().
  astearns: But path() is being implemented for *some* of the
            <basic-shape> properties.
  astearns: It's weird to have them linking to a definition in Shapes
            2 that's just a diff.
  astearns: One option is to flesh out Shapes 2 into an actual spec,
            with a proper definition for <basic-shape> including path()
  astearns: Another option is to pull path() back into Shapes 1, which
            implies we should implement it for shape-outside
  astearns: I don't much care which one we do.
  astearns: But would like to resolve on which way to go.
  TabAtkins: My preference is whatever gets all the props using the
             same set of shape functions; all the props use a
             different subset right now and it's terrible.
  TabAtkins: Spec's easy, I'm fine with it in level 1.

  astearns: I think Ian said doing path() in shape-outside wouldn't be
            trivial, but seems plausible to do.
  eae: Yes.
  astearns: So I propose adding path() to Shapes 1. There's other
            things that need to be done in the spec, we can get a
            draft out that everyone can refer to with all the
            functions.
  astearns: Can deal with how that slows down Shapes 1 from PR as we
            find impls to try it out.
  astearns: Objections?

  heycam: Any objection to shipping path() in things like offset-path
          - do they need to ship together?
  <AmeliaBR> The problem with adding path() to shapes 1 is that, as
             currently defined, it can't be used everywhere a shape
             is. It only defines the outline, not the fill area.
  TabAtkins: [reads Amelia's IRC comment]
  astearns: Yeah that's a bit of the problem, some properties don't
            need fill-rule at all.
  astearns: So I'm imagining it's an optional param to the function.
            But I haven't thought about how it's specified yet.
  heycam: Would that block Motion Path?
  astearns: My proposal is just to put it in Shapes 1. It should
            improve the Process situation for Motion Path; it can then
            refer to a CR-level spec instead of a FPWD diff spec.
  <AmeliaBR> Motion path would just ignore the fill rule. But for the
             SVG `d` property, allowing fill-rule in the path()
             function is possibly confusing, since there's a separate
             fill-rule property that applies.

  astearns: This is really all about Process.
  astearns: Tab, you mentioned Chris Coyier's annoyance with the
            shapes being different everywhere.
  astearns: There's the path attribute in SVG; it's possible we won't
            get all the way to SVG syntax in CSS.
  [discussion about CSS tokenization not being compatible with SVG]

  myles: Does that mean you can't build up paths from variables?
  TabAtkins: Not without defining a new syntax that's CSS compatible.
  AmeliaBR: Or doing the string-concat function.
  myles: Didn't we resolve to add that?
  AmeliaBR: Yeah, but no one's written it yet.

  AmeliaBR: wrt it being a Process issue; if we want to put path() in
            Shapes 1, we have to figure out these issues before Shapes
            1 can move forward in the process.
  AmeliaBR: I'm not sure who's responsible for Shapes's progress, I
            think Alan; at this point is it best to clean up and
            stabilize, or are we fine to take on this new work?
            Because it's also about impls.
  astearns: I think my strategy will be to add it to the spec as an
            at-risk feature, so that we can punt it if we need to move
            Shapes 1 forward, but I'm perfectly happy with it sitting
            at CR for a while, or even going back to WD if there are
            enough changes.
  astearns: I'm not that concerned with getting it to Rec real quick.

  AmeliaBR: Does adding path() mean we have to cycle back to WD, as a
            significant new feature?
  florian: Nah it's fine.
  florian: Patent Policy will handle it fine; as long as you've got
           wide review and what not is fine.
  AmeliaBR: It's been reviewed in Motion Path, but review there...
  florian: The easier it is to demonstrate review, the easier time
           you'll have.
  astearns: And if we have to bounce to WD, that's fine.
  AmeliaBR: So long term, is our goal that shapes should be shapes,
            and you should be able to specify motion-path with
            circle(), etc?
  TabAtkins: Yeah, a circle is a path, whatever.
  astearns: So any objection to adding path() to Shapes 1?

  RESOLVED: Move path() down to Shapes 1, adding it to <basic-shape>.

  krit: I missed - are impls willing to support path() in
        shape-outside?
  astearns: Missing a few people that would answer that.
  TabAtkins: Ian says it's non-trivial, but doable.
  astearns: So yeah that might slow us down, but getting things
            consistent and well-explained is more useful than a quick
            Rec for Shapes.

  krit: Would it be good to add a note about precision in paths? A
        very complex path might get transformed to a polygon, maybe
        have a lot of points, etc. So can we add a note that impls can
        decide on how precise it wants to be?
  AmeliaBR: I don't know if we currently have text to that effect with
            polygons...
  astearns: We do have text for some degenerate/difficult situations,
            saying you do have to do the difficult stuff.
  astearns: I'm not sure we need to define that; precision's going to
            be an impl detail. Tests will have to be fairly coarse
            anyway to avoid being flaky.
  astearns: So I think it's just a QoI detail they can live with.
  krit: So if we agree it's just QoI, it's probably fine.
  AmeliaBR: There's already a lot of flexibility for, say, *drawing*
            SVG paths.
  krit: Ok.

Sunsetting the fxtf-drafts repo
===============================

  AmeliaBR: This has already been decided, but there's been no
            volunteer to do the work.
  TabAtkins: I can do it.
  plinss: We'll need to add some redirects to the draft server, since
          the URLs will change. Coordinate with me.

CSS Lists
=========
  Scribe: heycam

Should list-item counter reset rule be in a UA stylesheet?
----------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/4244

  emilio: The CSS Lists spec says that ol and ul (should also include
          menu!) should have a counter-reset: list-item in the UA sheet
  emilio: We've had 2 regression reports, people overriding
          counter-reset
  emilio: The fix on the author side is trivial, adding list-item to
          the value
  emilio: afaik, the 2 regressions are fixed that way
  emilio: but we may want to think about whether we should make this
          reset magical
  emilio: The issue with making it magical, is that there's no way to
          override it to none

  TabAtkins: At the previous meeting, didn't we resolve to do the
             thing where if you don't mention list-item?
  emilio: That's for counter-increment
  emilio: Should we do the same for counter-reset?
  emilio: The reason I didn't want to jump to do that, there's no way
          to override it to none
  emilio: Could say you add the counter-reset, unless you explicitly
          set it to none
  emilio: so it's tricky
  emilio: Not totally convinced we need to change it for compat, but
          I'd like to know if we do need it
  TabAtkins: If we wanted to express the reverse behavior, in non
             magical ways, you'd need something special for
             counter-reset
  TabAtkins: the only way to do that within the syntax of
             counter-reset would be to add a function
  TabAtkins: because there's no comma, must be an ident and possibly a
             number. If you add a number ident, that's just another
             counter
  TabAtkins: If you wanted to change the behavior, like with reversed
             lists, syntax would be to use a function rather than an
             ident
  TabAtkins: Could have a dont-reset(...) when you explicitly need to
  TabAtkins: Then if it's not explicitly mentioned in this way, it
             gets reset in this way
  emilio: Not a fan
  AmeliaBR: counter-reset: dont-reset(list-item), xxx

  emilio: Just looking for ideas if we needed to tackle this
  emilio: for now this is fine I think
  emilio: A more web compatible solution would be to always reset it,
          but then it's annoying you can't override it
  TabAtkins: You can override the use of it
  TabAtkins: The browser's doing some extra accounting in the
             background, but the author just wouldn't use it

  fremy: What happens if you don't reset, and you have a reversed list
         inside another reversed list?
  AmeliaBR: It's a nested counter
  fremy: If you're not resetting the counter, you have to consider the
         nested child as part of the main list
  fremy: Does anyone want to implement that?
  emilio: I think it would work right now
  AmeliaBR: The list items handle if you're incrementing up or down
  emilio: We do the counting on the counter nodes, so we count the
          number of counter nodes that are in the same list
  emilio: I think it would work. Mixing reversed and non-reversed
          lists would be fun...
  fremy: Not sure it's a big problem if we cannot

  AmeliaBR: Any interested in supporting reversed counters in general?
            counter-reset and reset it to the max value the counter
            would have?
  TabAtkins: So far no, since that's not what reversed counters
             actually do in HTML

CSS Text 3
==========
  Scribe: TabAtkins

word-break:keep-all and overflow
--------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/4286

  florian: In langs like English, word-break:keep-all is same as normal
  florian: In Japanese, it suppresses a lot of wrapping opportunities.
           (Not quite all, but most.)
  florian: So if you have a very short measure of text, you might have
           a small sequence of text without break opportunities.
  florian: Currently there's a provision in the spec that the UA may
           reproduce the suppressed wrapping opportunity to reduce
           overflow.
  florian: I think this is good, but the "may" isn't. We should
           harmonize on should or must if we want to do this.
  florian: An example of this is a title or figcaption, a short piece
           of text.
  florian: People tend to like it not breaking anywhere in Japanese.
  florian: But if the amount of space is small enough that it would
           cause overflow, they'll prefer it to break anyway.

  myles: This value is for Korean, right?
  florian: It's frequently used for Korean, but it's also useful for
           other CJK languages.
  florian: Any language that allows breaking at syllable/char
           boundaries can use this to opt into a less free-form style.
  myles: Right, just if Korean use is most common for this, we should
         see what Korean native speakers prefer.

  koji: I'd prefer this be explicit, so it happens only when authors
        opt in, like overflow-wrap.
  koji: If you want overflow-wrap to not break at specific points,
        that might be the feature you want. I don't see much different
        from keep-all in English case.
  koji: If it's useful for Korean it's probably useful for English.
  florian: Difference between like-English and break-all is that in
           English, there's no real context where breaking anywhere is
           acceptable. But other languages, that is the default.
  florian: So falling back to that behavior in those languages that
           opt into keep-all is possibly reasonable, while it's not in
           English.

  myles: What about overflow-wrap:anywhere?
  florian: This isn't actually anywhere, tho.
  myles: Maybe break-word?
  florian: break-word and anywhere are identical except for intrinsic
           sizes.
  florian: But maybe we could have a fourth value, that says that if
           keep-all, it still falls back to breaking anywhere if
           necessary.
  myles: Right, my question is just if we need a new value, or if the
         existing values are enough and we just specify their
         interactions a little different.

  koji: In my mind, the two variants of Korean linebreaking are just
        variants; keep-all is normal behavior.
  koji: Even in English or German, if you have a tiny space to lay out
        in, you might still want a break going anywhere.
  florian: My proposal is *not* to allow breaks before commas, etc.
           Those are disallowed in 'normal'. My proposal is that, in
           these restrained-size situations, revert keep-all to acting
           like normal.
  koji: I understand. but this value is already to suppress this
        situation from happening in Korean. But I think we want to fix
        all languages.
  florian: We have this in german/english/etc by using hyphenation,
           with "" for the hyphenation character.
  koji: Ok, so say English text has a very long word, and the author
        uses overflow-wrap:break-all to allow it to break. In that
        case it can break before a comma, which isn't ideal.
  koji: I don't think we can change that, so we might want to add the
        fourth value.
  myles: That's what break-word was supposed to do way back when Hyatt
         implemented it...
  koji: word-break can be commonly used in an issue tracker, for
        example. But using it on English text is troublesome.
        overflow-wrap is more useful, but can do bad breaking.
  myles: My overall point is that the linebreaking properties in the
         Text spec are already so complex and there are so many of
         them, that it will be hard to justify another one.
  koji: Ok, well, I think this is basically the same as modifying
        keep-all.

  florian: One action item is to ask Korean speakers, since they're a
           frequent user of this value, if it would be generally
           acceptable or if it would be weird.
  florian: There seems to be a use-case to have it either way, but
           you're right, there is a big cost to adding new properties
           in this space.
  florian: So we could defer the always-prevent value if it's going to
           be rare.
  florian: It's just having the "may" that I think isn't terribly
           useful.
  myles: Right, making a resolution now seems premature.
  florian: Sure. That's enough feedback for now.

How to handle leading ideographic space sequences
-------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/4180

  florian: This has evolved over time; they're a strange kind of
           space, like figure spaces, ideographic spaces, etc
  florian: These now have the treatment that they're not collapsible,
           that hasn't changed, but they're discarded at the end of
           the line (assuming white-space:normal)
  florian: Unfortunate consequence: if the line is *only* these
           spaces, they're not discarded for being at the beginning of
           the line, but they're also at the end of the line and need
           to be discarded. That leaves an empty line, which is weird.
  florian: We could instead hang them.
  florian: Different option is you could still see them if you
           underline or background them.
  florian: But from layout, it would be the same as an empty line.
  florian: This was found by Igalia when implementing the spec as
           written, and it seemed weird to them.
  florian: I think there's no real author preference between
           discarding and hanging. So since hanging is simpler for
           impls, would be preferable.
  florian: I made a PR for this, I know fantasai is okay with this.

  stantonm: Is there precedence for having that many hanging spaces?
  florian: Yes, we have some other situations like
           white-space:pre-wrap.
  florian: There's an open issue for some variant situations, but...
  stantonm: The inline border does seem strange.
  stantonm: An inline with a border would project off the edge of the
            element.
  florian: Like any overflowing content, es.
  florian: Example: "<span>a b </span>". If the spaces can hang, these
           can stay on one line. If they can't and must overflow,
           instead you must break before b, then let that second line
           overflow anyway. So not hanging isn't avoiding overflow at
           all, just introducing extra linebreaks that shouldn't be
           necessary.
  koji: Hanging would require changes to our whitespace code that we'd
        like to avoid if possible.
  myles: There are like 5000 ways to make text look bad on the web
         already
  stantonm: Is there a way to avoid this?
  florian: Yes, text-underline-skip for example.

  astearns: So proposed resolution is to accept the PR, which states
            that the spaces will hang.
  astearns: Objections?

  RESOLVED: Trailing "other-separator spaces" will hang, accepting
            Florian's PR.

Shapes
======

Is it OK to ship clip-path:path()
---------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/4271

  astearns: There was a second gh issue we didn't send the comments to
  astearns: An impl was asking if it was okay to ship clip-path:path()
  astearns: Because they needed to point to an official draft that had
            this path() thing specified, and all they had was the diff
            spec
  astearns: So in my mind the intent of moving this to level 1 is to
            let impls ship it.
  heycam: clip-path:path() is already shipping in WK, I believe. Not
          in Chrome yet. Ready in firefox for a while.
  heycam: Just wanted to make sure nothing drastic would happen to the
          syntax.
  krit: CSS Masking is already in CR, so implementing clip-path is
        fine; this is specifically about the path() function.
  astearns: Does anyone think Gecko should *not* ship the syntax?

  RESOLVED: Impls can ship clip-path:path()

  heycam: What's the policy on this sort of "blessing"?
  <fantasai> if not CR, we put it into the Snapshot
  astearns: In general, CR means definitely fine to ship; before is
            usually behind a flag. But it's fine for there to be
            situations where people need to ship before CR, just check
            with the group that it's in a stable situation.

CSS Size Adjust
===============

text-size-adjust
----------------

  myles: People like to view websites on their phones.
  [general astonishment]
  myles: But phones are small. So the text is usually too small
  myles: So way back in 2007, iPhone 1 implemented a feature to
         automatically increase the text size without increasing page
         size.
  myles: We've been shipping this for a very long time.
  myles: This is controllable with a CSS property called
         -webkit-text-size-adjust
  <tantek> FYI some old writing on this here:
           https://wiki.mozilla.org/CSS/text-size-adjust
  myles: Three values: none, which means "don't mess with my sizes";
         auto, the default "mess with them it's fine"; and a %, which
         means the browser's default method of messing with sizes
         doesn't work well for a particular element, so they site
         provides its own % boost for the element.
  myles: So if font-size is 10px, and -webkit-text-size-adjust is
         130%, you'd see a 13px size.
  myles: So a bit later we shipped the iPad, also a small screen.
  myles: This wasn't a problem; we made the iPad view the same content
         the iPhone viewed; it pretended to be a big iPhone for the
         web.
  myles: So it also got the text-size-adjust behavior.
  myles: This past year we've changed iPad behavior.
  myles: Now iPads get desktop content.
  myles: So this means that sites which said -webkit-text-size-adjust,
         we don't get that behavior anymore.
  myles: But ipads are still small, so we have to do something.

  myles: After research, turns out the method we need to increase
         font-sizes is different between ipad and iphone
  myles: In iphone, the goal is to make text readable when you
         double-tap an element; we'll zoom in so the text fills the
         width of the screen, so you avoid scrolling.
  myles: In ipad, people don't usually double-tap on elements, so the
         goal was to make it readable by default.
  myles: So the heuristics are pretty different.
  myles: No problem so far.
  myles: This year we started accepting desktop content. That often
         has -webkit-text-size-adjust property, because desktops don't
         honor it, so it just kinda sticks around without doing
         anything.
  myles: But when we flipped the switch, ipads were honoring the
         property, and everything got messed up.
  myles: After investigation, we discovered that most of the sites
         that were setting -webkit-text-size-adjust were using 100%,
         which is the same as turning it off.
  myles: Correlation between sites that did that, and sites that
         *needed* -webkit-text-size-adjust to work well on the ipad,
         unfortunately.

  myles: So what we now have implemented in ToT is...
  myles: none still means none. auto still means magic; different than
         phone, but still magic.
  myles: But percent, we found that if treated percentages as auto, it
         made the web look better than honoring the percentages.
  myles: Way more sites were using %s to turn -webkit-text-size-adjust
         off, than were using it correctly to specify good sizing. In
         fact, *zero* sites were using it correctly.
  myles: So it would be good to write that down.

  myles: There is a spec covering this feature, CSS Text Size Adjust.
  <drott> https://drafts.csswg.org/css-size-adjust/#adjustment-control
  myles: I have a bunch of edits I'd like to make to that spec.
  myles: Mostly of the form that percentages will be used as a hint.
         On iPhones they'll be honored; on iPads they'll be a
         suggestion (currently ignored, might change later if sites
         start using it correctly).
  <karl> https://github.com/whatwg/compat/issues/18
  myles: And I'd also like to generalize the inputs/outputs for the
         "auto" behavior to make it encompass both the iphone and ipad
         behavior.
  myles: And I'd like to add a section about how authors should use
         the property to control this behavior; you can look at
         computed value to see what the browser did to your text, and
         you can use "none" to reset if it you don't like it.
  myles: So want to know what wg thinks.

  astearns: How are you speccing this behavior? UAs may do this, may
            do that...?
  myles: Strategy we thought best was to keep things general. Two
         behavior on two platforms, browsers might have other
         behaviors, etc.
  myles: As long as the author can know what was done and fix it,
         should be fine.
  myles: So strategy is to make it very general and have a list of
         things that may be considered when the browser does auto
         sizing.

  heycam: Seems like you want the author to be able to tell what auto
          adjust the UA has made for an element
  heycam: Exposed thru the computed style.
  myles: Already how iphone works
  heycam: Looking at the old spec for the moment; initial value is
          auto, and it's inherited. So if it computes down to the
          actual percent, wouldn't that be inherited to the children?
  myles: In webkit I think we don't follow the inheritance rules to
         the letter for this property.
  myles: If you stack a bunch of percentages, they don't multiply.
  dbaron: I heard you saying look at computed value of font-size, not
          text-size-adjust.
  myles: Right!
  myles: So you look at font-size and line-height; I think it's
         important that the spec explicitly says only those two
         properties will be modified.
  myles: So they know what to consult and fix.

  * karl wonders if apple has looked if when people specified
         -webkit-text-size-adjust if other browser extensions were
         specified or not.

  dbaron: I think most of this sounds fantastic.
  dbaron: A little nervous about generalization.
  dbaron: Would be nice to have a good description if someone wants to
          implement this...

  myles: So over the past long time we wanted to change how ipad
         viewed the web
  myles: but text was too small
  myles: The iphone's model isn't really what we want
  myles: Want different behavior, and faster (iphone behavior is
         slow), looks at viewport, style of nearby elements,
         out-of-flow vs in-flow, etc
  myles: Tried to come up with an algo for the ipad, and we
         implemented it, and it wasn't good
  myles: Cycled for a while.
  myles: So instead is we got a lot of humans to visit websites, and
         tap on the things that were too small. Custom webkit build
         that would log this
  myles: And then did the same to tap on the things that weren't too
         small
  myles: Then used ML to predict too-small vs ok-size.
  myles: So we have a decision tree, but...
  myles: it's not intentional. It just gives good results on a lot of
         pages.
  myles: So I think it would be a bad idea to put those results into a
         spec. Plus it can change later.
  dbaron: I think it would be useful to have it in the spec even if
          it's not required to be followed.
  myles: Maybe as a non-normative impl guide?
  myles: That's fine.

  fremy: If I'm an author and your algo gets it wrong, that seems
         unpredictable to me.
  myles: We try our best to make the heuristic good, and you can use
         "none" to fix it.
  tantek: You specifically gave examples of authors trying to shut off
          the behavior, but accidentally messing the pages up on other
          devices, and then you having to figure out what they really
          intended and correcting things for them.
  tantek: So that lack of predictability caused authors to misuse the
          property.
  TabAtkins: That's not right. When authors used
             -webkit-text-size-adjust on mobile devices, they did it
             reasonably right. The problem is that
             -webkit-text-size-adjust wasn't honored on desktop, but
             authors were still using (useless, ignored) declarations
             in their desktop-only code. As soon as ipad starting
             requesting desktop versions and honoring those
             declarations, it messed up.
  fremy: Ultimately if the heuristic isn't understandable/predictable,
         Stack Overflow will just recommend swapping 100% to "none".
  myles: And that's fine.

  emilio: So wk exposes the used font size...
  emilio: Your text adjust used to be layout time, right?
  myles: Yes. But on both iphone and ipad, if you say gCS().fontSize,
         you'll get the used style.
  emilio: Okay, that's not what Firefox does. But maybe we should
          change it.
  myles: Yeah, I think it's important.

  myles: So if the group thinks this is okay, I'll make a PR for these
         changes. They're pretty substantial, so maybe I could be
         added as a coeditor?
  tantek: I'm okay with that.
  <dbaron> +1 to myles as a coeditor

  SimonSapin: You said computed value of font-size is affected; does
              that mean that other lengths using em are affected
  myles: Yes
  emilio: It didn't used to be the case, right? If you did adjustment
          at layout time, you can't.
  myles: Hm, maybe I'm wrong.

  tantek: We never published a fpwd, we had too many issues and didn't
          understand how to get it good enough to publish.
  tantek: So maybe that's a good goal.
  myles: I think that's a reasonable goal.

  fremy: Do you apply the same heuristic for all ipads?
  myles: No, depends on screen size and viewport size and specified
         style
  myles: This is listed in the proposed changes
  fremy: So if there's a new version of the ipad, are these rules
         something that'll scale, or is it arbitrary? Do you have to
         do more tap testing?
  myles: I don't think I can answer that.

  astearns: So let's get edits into the draft and raise issues as
            needed.

  myles: The algorithm intentionally doesn't describe an algorithm
         currently, but it does describe things the browser can
         consider, and that it only affects two properties
  plinss: Do you turn these heuristics off when MQs are involved?
  myles: no
  myles: But <meta viewport> does interact with this
  myles: So if you have a webpage that is mobile-ready, that'll affect
         this algo
  myles: So the algo is only strong on webpages that are getting
         shrunk; if they fit well it has minimal effects
  plinss: Overall concern is just that we should be encouraging
          authors to just make pages in general and use MQs.
  myles: The overall purpose of text-size-adjust is to make things
         look good on small devices, so it's driving us toward that
         goal.
  myles: Philosophy maybe isn't productive, but generally: a solution
         in the UA works on every page, and doesn't rely on the author
         getting it right.
  myles: Users don't say "gee I wish this page used MQs" they say "I
         can't read NYT, this sucks"

  tantek: So a few times you mention hardware releases meaning new
          algos.
  tantek: I'm uncomfortable with algo changing with hardware releases.
          That's not a standard.
  tantek: I'd prefer something that survives hardware releases.
  myles: First, if we release a new device, we're gonna have to tweak
         it. The web'll look bad, we have to make it look good.
  myles: Second, restricting this to exactly two props, and telling
         authors how to change it, goes as far as we can to that goal.
  myles: So the most future-proof we can do is to say that
         text-size-adjust can only affect font-size and line-length;
         no matter how the browser changes things, the author can
         always look at those properties, and disable text-size-adjust
         if they want.
  TabAtkins: And note that myles wasn't originally intending to
             publish the algorithm at all, that was a dbaron request
  tantek: I'm concerned that this'll be continuous reverse engineering.
  myles: Yeah, when android ships another phone, they'll have to do
         the same sort of engineering.
  hober: This is just acknowledging reality
  dbaron: And realizing that the web's behavior will justifiably
          change over time. Maybe that means the spec will need to
          change over time too.
  dbaron: In a world where devs test on these N devices and not every
          possible-in-theory form factor, there will be things that
          break when a new device comes out. That'll always be the
          case, and the impl might need to do new things.
  dbaron: So I'd rather have a spec that evolves over time to reflect
          that
  myles: So the alternatives.
  myles: One is a spec that changes all the time and is only good on
         one device, not great.
  myles: Another is don't spec it at all, and have it just be magic.
  myles: I think I've described a good middle ground.

  dbaron: Commenting back on the plinss/myles convo
  dbaron: I think using MQ as a signal is a bad idea.
  dbaron: It's a passive mechanism. One random stylesheet might use
          MQs, and if that changes the behavior, it can be a
          disincentive.
  dbaron: So for this sort of thing, I think meta-viewport is a better
          signal.
  <karl> spec it. at least in compat for now.
  <fantasai> I would prefer to not put more and more rendering
             instructions into HTML?
  tantek: I think I need to see the PR to make more comments, so I'd
          like to make you a coeditor, make the edits, and have
          continuing discussion
  myles: Yeah, not asking for you to pre-approve things you haven't
         seen.

  RESOLVED: Add Myles as co-editor to CSS Size Adjust.

  <karl> \o/ yeah!
  astearns: And I think we have a general agreement to specify
            text-size-adjust. Objections?

  RESOLVED: Specify text-size-adjust more fully.
Received on Friday, 4 October 2019 22:52:57 UTC

This archive was generated by hypermail 2.3.1 : Friday, 4 October 2019 22:52:58 UTC