- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 04 Sep 2013 16:33:15 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- RESOLVED: UNICODE-RANGE token changed (in Syntax & CSS2.1) to be more
restrictive in what it takes, per Tab's proposal.
(No changes to Fonts.)
- RESOLVED: Fonts Level 3 to CR
- RESOLVED: Cascade L3 to CR
- RESOLVED: TCY doesn't disable font-variant: full-width. Revisit if
fonts start to become popular that would benefit from this
extra interaction.
- Discussed improving gradient stop color fixup rules for better transitions
http://lists.w3.org/Archives/Public/www-style/2013Aug/0296.html
- Discussed handling Media Queries 3 errata
====== Full minutes below ======
Present:
Glenn Adams
Rossen Atanassov
Tab Atkins (late)
David Baron
Bert Bos
Dave Cramer (Hachette)
John Daggett
Jason Erenkrantz
Elika Etemad
Simon Fraser
Daniel Glazman
Rebecca Hauck
Dael Jackson
Brian Kardell
Brad Kemper (late)
Philippe Le Hégaret
Chris Lilley
Peter Linss
Edward O'Connor
Florian Rivoal
Anton Prowse
Simon Sapin
Dirk Schulze
Alan Stearns
Leif Arne Storset
Lea Verou
<RRSAgent> logging to http://www.w3.org/2013/09/04-css-irc
Agenda: http://lists.w3.org/Archives/Public/www-style/2013Sep/0061.html
Scribe: fantasai
plinss: Any additions to the agenda?
CSS3 Fonts
----------
Topic: Unicode-Range Parsing
SimonSapin: In the Syntax spec, some changes from CSS2.1
SimonSapin: Tried to match Fonts spec, do parsing/normalization of
unicode-range in tokenizer
SimonSapin: But fonts spec changed
SimonSapin: So want to revert changes, and do what CSS2.1 does for
UNICODE-RANGE
SimonSapin: Tab prefers to do parsing in Syntax, have UNICODE-RANGE
return pair of integers rather than string
fantasai: Well, I know we have implementations of the 2.1 tokenization
SimonSapin: They're not testable
dbaron: Some cases can be tested via obscure counter-reset/increment
declarations
dbaron: But don't think it's worth worrying about
<dbaron> http://dbaron.org/css/test/2013/urange-token shows detecting
UNICODE-RANGE with counter-increment
dbaron: 2 questions - what is the desired behavior, and which spec?
dbaron: So first, what's the desired behavior
jdaggett: Desired behavior in terms of ... ?
dbaron: What are the differences in behavior that we're discussing?
SimonSapin: Fonts spec changed details of UNICODE-RANGE parsing in last WD
SimonSapin: e.g. ranges beyond Unicode used to be clipped, but are
now invalid
jdaggett: How does that impact Syntax?
SimonSapin: Because Syntax defines tokenization
SimonSapin: Syntax used to do clipping in the tokenizer
jdaggett: Only opposition is Tab, and he's not on the call atm
SimonSapin: What came out of ML discussion with Tab, was compromise
SimonSapin: Tokenizer would have pair of integers
SimonSapin: Leave to fonts what to do with integers, depending on whether
increasing/decreasing etc.
SimonSapin: Just two integers given back
<SimonSapin> http://lists.w3.org/Archives/Public/www-style/2013Sep/0019.html
jdaggett: impact of what we're talking about is whether parser takes
something as UNICODE-RANGE or not
jdaggett: Cases where author will want to use that syntax somewhere
else is almost never
SimonSapin: Proposal is to remove section in Syntax that defines
unicode-range range restrictions
SimonSapin: ie. removing this section:
https://dvcs.w3.org/hg/csswg/raw-file/aa1b58939f73/css-syntax/Overview.html#set-the-unicode-ranges-range
* fantasai is biased towards Simon's position over Tab's
plinss: Does this impact Fonts, which is going ot CR?
TabAtkins: Could remove stuff from Fonts spec, because covered by Syntax
fantasai: Don't think we should be removing anything from Fonts spec,
Syntax is kindof early stages, would like Fonts to be complete
as of now.
jdaggett agrees
ChrisL: Don't want Fonts spec to change
ChrisL: Given it's going to CR
TabAtkins: UNICODE-RANGE in CSS2.1 accepts syntax that will never be
needed/used
TabAtkins: Would like those cases to not parse as UNICODE-RANGE.
TabAtkins: But fine with range-restrictions staying in Fonts spec
...
TabAtkins: I would like to kill U+1?3
TabAtkins: Want to make that invalid at the tokenization level
<SimonSapin> examples of bad syntax: U+1?3, U+1?-30
<fantasai> I think the second one is already invalid in 2.1
<SimonSapin> fantasai, it is valid in 2.1
<SimonSapin> 2.1’s definition: u\+[0-9a-f?]{1,6}(-[0-9a-f]{1,6})?
plinss: Any other comments?
fantasai: No changes to Fonts spec, right?
Right.
fantasai: So only question is whether UNICODE-RANGE token uses the 2.1
syntax or Syntax syntax
jdaggett: [talks about splitting definitions across specs]
fantasai: If we're changing definition of UNICODE-RANGE, we need to
errata 2.1
fantasai: Can't have two different definitions depending which spec
you read
plinss: Anyone objecting to Tab's change?
TabAtkins: Simon's proposal was to accept 2.1 syntax, and have Font's
processing make things invalid.
SimonSapin: I'm fine with Tab's proposal as well
fantasai: Only thing that bothers me is that we have implementations
on the 2.1 tokenization
fantasai: They'd have to go back and change
TabAtkins: It's (for the most part) author-undetectable
Bert: I'd like to see the regex first, if that's ok
TabAtkins: Ok, I will send to ML
RESOLVED: UNICODE-RANGE token changed (in Syntax & CSS2.1) to be more
restrictive in what it takes, per Tab's proposal.
No changes to Fonts.
<SimonSapin> Bert, TabAtkins: regexp equivalent of the proposed change
to unicode-range:
u\+[?]{1,6}
u\+[0-9a-f]{1}[?]{0,5}
u\+[0-9a-f]{2}[?]{0,4}
u\+[0-9a-f]{3}[?]{0,3}
u\+[0-9a-f]{4}[?]{0,2}
u\+[0-9a-f]{5}[?]{0,1}
u\+[0-9a-f]{6}
u\+[0-9a-f]{1,6}-[0-9a-f]{1,6}
<TabAtkins> SimonSapin, Bert: Yeah, I was drawing up a slightly different
one, but it's functionally identical, and yours is somewhat
clearer.
<jdaggett> http://dev.w3.org/csswg/css-fonts/doc-20130711-LCWD.html
plinss: Fonts to CR?
jdaggett: There was one outstanding issue on 'ordinals', but that got
cleared up over ML with examples/pics.
jdaggett: Question is, do we need another LC or go to CR?
jdaggett: I don't think there's a huge impact on implementations from
any of these changes.
jdaggett: Most significant change is removing 'auto' value
fantasai: I don't think we need to go through another LC, changes
aren't very major.
ChrisL: Spec is currently listing everything as major changes, most
are minor
ChrisL: But several are substantial [lists]
ChrisL: Reorder feature precedence, 'auto', etc.
ChrisL: All these need to be addressed, and argue that they are minor
ChrisL: I'd rather not do another LC
jdaggett: Auto value was never implemented
jdaggett: Not part of CSS2 spec
jdaggett: Only removing a single value, that was never implemented
[process discussion]
<dbaron> I think ChrisL was saying that we need to argue that the
changes weren't substantive in order to go from LC to CR.
<dbaron> (for minutes)
<ChrisL>
http://services.w3.org/xslt?xmlfile=http://www.w3.org/2005/08/01-transitions.html&xslfile=http://www.w3.org/2005/08/transitions.xsl&docstatus=cr-tr
<ChrisL> quote "Some reasons for declining a transition request
<ChrisL> The technical report has been substantively modified since
the previous transition. In this case, the document is returned
to the Working Group for further work."
jdaggett: So I should revise Changes section to not list changes as major
jdaggett: Could also add an "impact" statement, to describe what the
impact is on implementations
jdaggett: For most of these, no impact, because there aren't implementations
[discussion of how to style DoC]
[more discussion of handling DoC]
ChrisL: I'm trying to be pre-emptively awkward here, to make the
transition call go smoothly
plinss: I get your point Chris, and but for this point, i don't think
this is worth taking up group time
plinss: I'd rather take up 10 min of transition call time than 10 min
of CSSWG telecon time
plinss: Any objections to CR?
SteveZ: Sent email this morning on 'ordinal' issue
SteveZ: I have no text that's there, just want to point out that there's
an aspect of ordinals that is in the OT definition, that really
no longer applies
SteveZ: The original conception of 'ordinal' feature was that you could
mark a paragraph, and it would ordinal everything that was number
followed by letters
SteveZ: Problem was that writing rules for all languages was troublessome
SteveZ: So you need to apply the feature around just the numbers
SteveZ: as the example shows
SteveZ: Might want to say that in the text
jdaggett: Don't think it's necessary
jdaggett: I can add to the sentence within the example, just to indicate
that it's not applied to the paragraph
SteveZ: That sounds good to me
SteveZ: Just want a warning to not apply it to the whole paragraph
jdaggett: Any objections to CR?
fantasai: No, let's do it!
<ChrisL> none at all
RESOLVED: Fonts Level 3 to CR
ACTION ChrisL Send transition request
<trackbot> Created ACTION-576
CSS Cascade L3
--------------
http://dev.w3.org/csswg/css-cascade/issues-lc-2013
fantasai summarizes all the comments
<glazou> go ahead!
RESOLVED: Cascade L3 to CR
CSS Writing Modes L3
--------------------
Topic: text-combine-horizontal and font features
* fantasai sent email to jdaggett on this just now
fantasai: [summarizes discussion]
Since full-width glyphs don't compress well, we are trying to avoid
using them in TCY (by transforming out from full-width codepoints, etc.).
Currently the spec says that 'font-variant: full-width' is ignored
for this reason. jdaggett says that there aren't any fonts that use
different glyph shapes for 'font-variant: full-width', so nobody
would use it in vertical text, so there's no need to have this
feature interaction. I'm fine with that, as long as we're open to
reconsidering if we end up with fonts that do use different glyphs
for 'font-variant: full-width'.
jdaggett: I'm fine with that
SteveZ: Can I raise a related issue?
jdaggett: Can you raise it on the list?
plinss: Will it impact this discussion?
SteveZ: Don't know
SteveZ: When I contacted Adobe font people about compression issue,
they basically said "don't do that"
SteveZ: So I had a private conversation with Koji, who said "but we
have to do that, because the WebKit based publication guide
wants to be able to ensure that all their text fits within
an em-square for body text"
SteveZ: Issue I'm concerned about is making the default for text-combine
do the compression
SteveZ: Rather than have a property to turn it on
SteveZ: Which would remove many of the cases that we seem to be stumbling
over
jdaggett: This issue is exactly what we discussed 1.5 years ago.
jdaggett: We had a property to control it
jdaggett: But seemed overkill to me
jdaggett: Maybe post to the list, what you want
jdaggett: We've added this property, and then took it out, and now
you're leaning towards bringing it back
SteveZ: What I want is not have the default be compression
fantasai: reason default is compression for CSS and not for InDesign
is that in InDesign author can see and tweak the result and
will adjust it; in CSS author doesn't see it and doesn't
know exactly where lines will break, etc.
fantasai: It's very important for publishers not to have overlap.
Can't manually check with CSS. So better to force 1em
compression so they can guarantee there's no conflict.
jdaggett: I'd like to capture the resolution that for now we take out
the automatic disabling of full-width variants
fantasai: As long as we are ok to reopen if we wind up with fonts that
would benefit, I'm ok with that.
RESOLVED: TCY doesn't disable font-variant: full-width. Revisit if
fonts start to become popular that would benefit from this
extra interaction.
CSS Image Values L3
-------------------
Swapping order of color stop fixup
TabAtkins: Gradients require color stops to be in order
TabAtkins: If not, push later ones to position of next position
TabAtkins: Rules for fixup right now they work, but result in weirdness
for animations.
<smfr> http://lists.w3.org/Archives/Public/www-style/2013Aug/0296.html
TabAtkins: Step 2-3 requires layout infos
TabAtkins: Back when doing gradients, Shane suggested changing this
TabAtkins: I think we shot this down because fatigued with gradient
changes.
TabAtkins: But should revisit
TabAtkins: Small change
TabAtkins: Rendering change is fairly minor
TabAtkins: And not likely to be many cases affected
TabAtkins: So suggest swapping order of steps, so that can transition
gradients without requiring layout.
Lea: Any specific examples that would change?
<TabAtkins> http://dev.w3.org/csswg/css-images/#color-stop-syntax
<TabAtkins> linear-gradient(red 100px, blue 0px, white, yellow 200px)
<TabAtkins> currently, fixup moved the blue one first, then figures
out the white position, so you get
florian: If we do this, should go into L3
krit: We don't order when we have transitions?
krit: Asking, you asked to move the ordering step to the last possible
krit: When you have transitions, you do not order the color stops
TabAtkins: Correct
TabAtkins: You position first/last stops and interpolate
TabAtkins: Then at layout time do the stop fixup
krit: Ok, I'm fine with this
<TabAtkins> so currently, you end up with
red 100px, blue 100px, white 150px, yellow 200px.
<TabAtkins> With my change, you'd end up with
red 100px, blue 0px, white 100px, yellow 200px
<TabAtkins> and at layout, it'd be fixed up to
red 100px, blue 100px, white 100px, yellow 200px.
<TabAtkins> but you'd do transitions with the prior one
Leif: Given implications of this, I think I'd like some time to review
TabAtkins: Ok
plinss: Come to back to this for F2F
MediaQueries 3 Errata
---------------------
dbaron: There was a thread, someone pointed out obvious mistake in 2 places
dbaron: Mistake is in REC errata
florian: I've updated MQ4, asked plh to update errata
plh: Haven't processed email yet, but should be done today
florian: Ok, thanks!
florian: As for folding them into MQ and publishing updated REC, we
thought to wait awhile to do that.
florian: Maybe we'll run into more issues
florian: Maybe wait until end of year
fantasai: Maybe aim for TPAC
fantasai: Put it on TPAC agenda, assign any relevant action items then
plinss: F2F next week, please add your items to agenda so we can use
time productively!
Meeting closed.
Received on Wednesday, 4 September 2013 23:33:44 UTC