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