- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 04 Feb 2014 01:11:16 -0800
- To: "www-style@w3.org" <www-style@w3.org>
Media Queries
-------------
- Discussed process of fixing trivial errors in MQ3
- RESOLVED: Update MQ3 wording on never having to evaluate a style sheet
unless specified explicitly otherwise.
- Florian and Tab presented an overview of the changes in MQ4, particularly
- deprecating types in favor of features
- specific media features being introduced
- introducing mathematical comparison syntax in addition to min-/max-
- expanding list of falsy values
The CSSWG gave feedback, including various fixes and ideas to explore.
(See full minutes.)
- RESOLVED: add value < feature syntax (value op name form), including =
- RESOLVED: publish FWPD of MQ4, add Tab as editor
Baseline Grids
--------------
- RESOLVED: add astearns, fantasai as editors to line-grid module
- RESOLVED: publish FPWD css-line-grid
CSS3 Color
----------
Reviewed status of currentColor erratum / implementations
====== Full minutes below ======
Media Queries
-------------
Scribe: tantek
<florian> http://lists.w3.org/Archives/Public/www-style/2013Nov/0122.html
florian: MQ3 errata
florian: need to fix example in a REC
florian: we have an errata for MQ3 but that typo is not in it
plh: updating errata is easy
plh: but a new REC is harder
florian: updating errata is good enough
fantasai: you can fix the typo in place
florian: whoever can touch these documents please fix
bert: I can fix the errata
<florian> http://lists.w3.org/Archives/Public/www-style/2013Nov/0125.html
florian: the other MQ3 topic
florian: it says something about never having to evaluate a style sheet
florian: I have proposed wording
florian: do we want to change this in level 3?
florian: or we can just do it in 4
florian: in level 4 it is already fixed.
glazou: fix it in both
glazou: no objections, resolved.
dbaron: does it make it clear that it is unless explicitly specified
florian: yes
dbaron: it might be good if it was "… that it overrides this rule"
tab: ok
<SimonSapin> +1 dbaron
<dbaron> explicitly specified that it overrides this rule
RESOLVED: Update MQ3 wording on never having to evaluate a style sheet
unless specified explicitly otherwise.
<dbaron> (This is based on an interesting idea I read about... I think
it was from Canadian law ... there are a set of legal rights
that the government can't override unless the law overriding
the right explicitly says that it violates that right... so
that it can't happen by accident or be hidden.)
tab: MQ4 changes
tab: I am going to ask for first public WD
tab: we are deprecating a bunch of media types, replacing them with media
features
tab: TV never succeeded because your screen style sheets were not allowed
tab: MQ4 proposes saying: media types are a legacy feature
explicitly supporting: all, screen, print, speech
fantasai: would it make sense for tv & screen to simply be non-exclusive?
tab: no one is publishing tv style sheets
tab: beyond epsilon
florian: what Opera did with projection was fairly strange
* fantasai thought it was pretty useful, though
glazou: what about number of screens and resolutions of screens?
glazou: we are concerned about the second screen experience
tab: yes. please bring it up in an email thread.
tab: also, new range context syntax
tab: authors seems excited about this
<glazou> +1
tab: old min/max features still supported, but they just map to the
inequalities versions
tab: could be convinced to add !=
tab: single equal or double qual?
smfr: what about != ?
dbaron: what about = ?
(too many talking)
dbaron: also want value < feature, given that they have
value < feature < value
tab: yes
bert: we have avoided < > in CSS to allow it better in HTML
tab: it works now
bert: HTML hasn't changed
tab/bert have CDATA arguments
shepazu: HTML5 has parser than handles it
bert: not just browser, talking about HTML, XML etc.
bert: you have to escape it in some cases
tab: if no one escapes it they won't have a problem
bert: if you use SGML you're going to have a bad day
<glazou> (laughter)
<dauwhe> I have styled docbook with CSS, but I'd be fine with escaping
< if needed in that situation.
tab: we should add = sign
RESOLVED: add "="
tab: we need a use case for not equals
RESOLVED: add value < feature syntax (value op name form)
tab: in addition to name op value form
tab: we are looking for use cases for the != form
tab: MQ4 syntax has been rewritten but should be functionally equivalent
Tab: We agreed to add full and/or/not logic like @supports, but I haven't
done that yet; plan to.
glazou: if we're using media features instead of media types we're going
to replicate that list of features many times in many @-rules
and I don't want to see that
<glazou> we need a way to declare a user-defined media type based on a
list of features
florian: not in the spec now but we should talk about it
florian: another minor change, when you just evaluate a media feature
inside a parentheses we used to special case it
tab: none is now falsy as well as 0
tab: it prevents us from going down the route of having a boolean that
takes 0 and 1
tab: new media features
tab: "updates" feature (name pending) - how quickly the screen updates
tab: updates: none is like printing
tab: updates: slow is saying not good enough for animations, like e-ink
tab: updates: normal can handle animations
tab: open to input on names and frequencies
dauwhe: Call this refresh-rate rather than updates?
florian: rate sounds like a number
florian: and we don't want that
<sgalineau> update-frequency high/low?
<fantasai> Also, mention animations in the description of 'normal'
tab: next two is how you deal with overflow
tab: "overflow-block"
tab: none or scroll
fantasai: opera had a mode where it could do forced page breaks or
otherwise it would scroll which was cool for presentations
tab: is that addressed by paged?
fantasai: I think it is a new one
dbaron: it is can-you-make-page-breaks, not does-overflow-go-into-new-pages
tab: it only applies if you are paged already
tab: better to have two variants of paged?
[...]
florian: would have to name it something else
smfr: terminology is very confusing
smfr: overflow block and scrolling is already used in CSS
tab: we tried to use parallel naming but that might be confusing
tab: better names are requested!
smfr: content doesn't overflow the screen, it overflows the viewport
tab: you're right that should be viewport
tab: can we split paged into two values that better capture it
tab: and we'll solicit better names for the properties themselves.
tab: sound good?
(no objections voiced)
tab: (more new features)(
tab: "pointer: none
florian: like paper, TV without a cursor
tab: … other value, like a mouse
tab explains pointer: coarse | fine vs. hover: none | hover
(markup discussion of spec example)
tab: "hover" is a new media feature
tab: whether hovering is supported or not
florian: we are not addressing the keyboard
(disappointed in minute taker for not capturing an overflow joke)
tab: some devices can match multiple values
tab: e.g. chrome pixel is both touch and pointing device
tab: e.g. both coarse and fine
tab: in general we say match according to primary input devices
tab: if it's just a possible input, don't match
florian: connecting a mouse to a tv does not turn it into a desktop
tab: next, "luminosity"
smfr: this is the wrong term
glazou: we should use device API terms
glazou: This is called light-level
...
tab: we should capture that luminosity should be named light-level
glazou: there are a lot of device APIs we could add as media queries
glazou: e.g. new samsung phones have capability of detecting to see
if someone is looking at the phone
plinss: so you can restyle the page to look different when you're not
looking at it
(laughter)
tab: should be careful with things useful declaratively or just in script
tab: but there's a goldmine of things we should add
shepazu: have to be careful with pointer events
tab: script
tab: whether or not ecmascript is supported on the current document
shepazu: "script" in the CSS context might be confused with i18n script
shepazue: how about procedural scripting? something other than "script"
shepazu: scripting would be less confusing
fantasai: should be something about supported languages
fantasai: none | js | dart
tab: switch "enabled" to be actual scripting language names
tab: a third value might be useful (in addition to none | enabled)
tab: UAs like opera mini run scripts on page load and then never again
tab: is that useful ?
plinss: similar to printing
plinss: so yes it is useful
tab: then I want two different features
tab: whether scripting is allowed at all
tab: and then another feature for supported language(s)
florian: I don't think there is a pressing need for detecting which language
fantasai: what about user pref'd off?
tab: those are just "none"
plinss: there are many sites that say, "your scripting is turned off,
please turn it on" - horrible thing to say if you can't turn it on
dbaron: there are plenty of sites that do that via a div in markup and
set it to display none in script
plinss: … (couldn't hear)
tab: the way the syntax is defined, both such values should be falsy
tab: we could make the set of falsy values extensible
florian: ?
tab: if it gets fine grained enough you need a JS API
florian: (something) might eventually be needed
tab: will leave it as an open issue - do we want two flavors of none?
tab: will add a feature for can-only-run-script-on-load
SimonSapin: fingerprinting concerns?
tab: a lot of them are already exposed in other ways
tab: if there are new exposures, open to ways to deal with that
glazou: devices, keyboards
glazou: some devices have keyboard that slides out
tab: captured by "work properly" vs "horrible"
tab: lots of open questions about keyboards
tab: many sets of devices these days
tab: yesterday we discussed print economy
tab: some things that are static will want full backgrounds
tab: some things like printers may want to do economy mode
simon: If ink-economy is a CSS property, it may be problematic to query
it with MQ
florian: is that what media queries are for?
florian: e.g. if black everywhere is expensive...
tab: yes, that's my basic thought
tab: the property allows you to opt into the browser's blunt hammer -
e.g. economize ink usage
tab: it might be valuable to allow more fine grain user / author input
tab: microsoft has a high-contrast media query
tab: how does it work?
rossen: the latter (that you've been put into high contrast mode and
you should adapt)
tab: also, inverted
tab: is it forced or requested?
rossen: same way
plh: we looked into that related to the canvas API
plh: re: custom focus ring
plh: only supposed to draw focus ring if special request from user
plh: it is not clear if browser has access to the information
plh: e.g. on Windows it is controlled by the OS
plh: but did not tell the browser
plh: you may want to be careful
plh: maybe some privacy implication
plh: people using high contrast may have some disability and may not
want to give that information
tab: there was a discussion in Shenzen about this
tab: all that indieUI mediaqueries, do we want them in MQ4 or leave
them in an extension?
plh: maybe wait a while before you do that
plh: to see how successful they are
fantasai: best to pull them all into one spec
bert: otherwise people will have hard time finding them
tab: they don't have that many
tab: but a bunch of them should be pulled in
fantasai: concerns e.g. with inversion is there are various ways of
inverting, as discussed in Shenzhen
tab: we need a way to say this is an image, don't invert it
tab: but still want a mq for inversion to turn off shadows
tab: being able to actually alter your styling in response, beyond
just un-inverting images, is still useful
tab: I will look into pulling in indieUI things we've discussed
fantasai: another one ...
tab: kinda
fantasai: e.g. dark theme
tab: that's interesting
tab: might be a good direction to go in, preferred theming
tab: final issue - view-mode
tab: seems half reasonable
tab: should properly pull it in and get it properly tested in real browsers
smfr: generally deprecating media types, bunch of other specs refer to them
smfr: e.g. animations says if you're media type print you should not animate
smfr: things they can be converted to?
tab: animations should just refer to the "updates" media feature
simonsapin: media line?
(in property definitions)
tab: we should fix that
bert: I use some of these media types!
bert: they should keep working
bert: they work in opera
bert: projection, handheldd
florian: not since 2007
bert: also in openwave
bert: deprecating is fine, but don't change their meaning
tab: old browsers can do what they want
florian: new browsers won't match them
bert: that's a problem
tab: won't work on my phone
bert: they have bad browsers
tab: these media types are not used in practice
bert: no
plh: perhaps deprecate but still support instead of drop?
shepazu: we're talking about for browsers made today and in the future
bert: ok to add new functionality
bert: but not ok to break existing documents
tab: but those don't work in 99.99% of devices
bert: but that's a bug in those browsers
bert: so how do I get my projection?
glazou: projection is completely undefined
bert: but it works
tantek: projection only worked in one implementation. claiming we should
support those documents is like saying all browsers should support
-webkit- prefix features.
bert: but projection was in a standard
dbaron: The thing Opera did with projection is nothing like what the
spec said.
(lots of talking)
florian: this document at an editorial level was a major rewrite
florian: please review to make sure we didn't change meaning of existing
features (unintentionally)
glazou: next step
tab: request FPWD
glazou: who agrees on FPWD
glazou: who objects
glazou: consensus FPWD MQ4
tab: also I need to be an editor
<dbaron> (probably about 2/3 or more of the room in favor, and no
objections)
glazou: who will publish it? staff contact?
shepazu: had a long conversation Sunday about projection
shepazu: some additional use cases
shepazue: 1 notes on screen but not visible on projector (second screen
thing)
shepazu: 2 change contrast when it is being projected, higher contrast
3 full screen on the projection and not necessarily on your main screen
florian: e.g. if you try to replicate Powerpoint in a browser
shepazu: if you mirror screens, is that OS level and you can't effect?
we aren't sure how we're going to address all this
smfr: two of those things sounded like you wanted two views of the
same document
clilley: there are other contexts we've discussed that
RESOLVED: publish FWPD of MQR, add Tab as editor
Baseline Grids
--------------
astearns speaking/ presenting
astearns: had a problem, and with CSS in general
astearns: (sets up projector)
astearns: have been using this as an example of baseline grids
astearns: they have side by side content, and none of the baselines
align across columns
astearns: it would be great to have a way to share a baseline grid
astearns: so that the columns could share baselines in body text
astearns: it would be great if CSS could address this problem
astearns: having line boxes align to a grid is a first step
astearns: you want a way to say I want these lines to participate
in a grid and others not
astearns: e.g. body text stays on the grid
astearns: or giving blocks a way to align to the grid in interesting ways
astearns: e.g. having the first baseline of the element align to the grid
astearns: or having the entire block center on the grid
astearns: in either case you get a much better layout
fantasai: I wrote a proposal, but the WG decided it wanted to put in
the line Box module, which is not in a publishable state,
therefore has been blocked from publication last 2-3 years
simonsapin: line-grid module?
astearns: yes
<dauwhe> http://dev.w3.org/csswg/css-line-grid/
<hober> IIRC we based -webkit-line-clamp on fantasai's proposal
<SimonSapin> fantasai, Line Box, is it Line Layout / css-inline ?
<fantasai> yes
szilles: critical part, what gets aligned, and how big is it
astearns: does fantasai's proposal handle it?
szilles: not clear
szilles: the way CSS does line boxes, not clear if you can determine
the baselines
astearns: there has to be because flexbox does some first baseline
based alignment
clilley: would be nice to see more alignment
clilley: e.g. align by-lines to each other at the bottom
clilley: second comment, also drop caps, n lines below the baseline
clilley: 3 other alphabets align to top line etc.
astearns: sometimes it's not the baseline, sometimes it's some other
typographic measure, e.g. CJK centers the content
fantasai: actually, it aligns to a baseline as well -- happens to be
the central baseline rather than alphabetic baseline
szilles: don't want to take ruby into account when doing the alignment
fantasai: alignment with ruby is already defined in ruby spec
astearns: problem of aligning lines to baseline grid while bottom-aligning
the content
astearns: (other problems)
szilles: also widows and orphans
bert: ...
<Bert> (Like leader(), but vertical.)
astearns: the main relationship depends on the order in the block
direction
astearns: how tall it is when you are bottom aligning it, then relates
to grid, then loop
astearns: I would like to work on this
astearns: perhaps I can help co-edit Line Box Module
szilles: ...
fantasai: let's publish both of them, and continue working on both
clilley: ?
florian: how can we depend on baselines without defining them?
tantek: because baselines are shipping
<TabAtkins> Tantek, *something* is shipping, which vaguely resembles
what we typically call "baselines". That doesn't mean
it's something we can write further features on top of.
fantasai: so far both modules are just referencing 2.1
fantasai: once they both exist, cross referencing would of course
be better
clilley: if they both reference 2.1, just publish
fantasai: that would be better than waiting for line-layout module imo
clilley: much more eyes on it by publishing it
<tantek> TabAtkins, flexbox would seem to be an existence disproof
of that statement. ;)
<TabAtkins> Flexbox is a minor violation of that statement. It only
barely touches baselines. ^_^
(as a further feature on top of "baselines")
<fantasai> http://dev.w3.org/csswg/css-line-grid/
<fantasai> http://dev.w3.org/csswg/css-inline/
fantasai: these are the two modules we are talking about
glazou: are we done?
astearns: I would like to start with fantasai's proposal
shepazu: I second that
glazou: but where?
fantasai: ok to publish as its own module
fantasai: and merge later
glazou: summarize?
dbaron: so I don't entirely understand what the line grid spec is saying
dbaron: should we - if we're going to publish this can discuss it a
few minutes
florian: we reviewed it in Kyoto
dbaron: the line-grid property seems global rather than an ancestor
chain which seems weird
dbaron: seems to imply a temporal things
dbaron: would be better if it said ancestor
dbaron: that should be clarified
fantasai: agreed
bert: seems overkill. should be ok to say this element defines a grid
or not.
bert: you don't need an identifier for that
szilles: the reason you need identifier is you may have two grids going
at the same time. one for figures and one for text
bert: seems a bit far fetched
bert: would like to see it based on ancestors first
szilles: would prefer some discussion first
clilley: we discussed at hamburg
szilles: issues raised in Hamburg were not handled
clilley: it is ready for FPWD
clilley: if there are outstanding issues, then put them into the draft
and publish
tantek: agree with chris
fantasai: it wasn't discussed in Hamburg, it was discussed in Kyoto 2.5
years ago
glazou: we agree that we add known issue to the document?
fantasai: only known issue: wanting to simplify to only use ancestors,
not identifiers
szilles: my issue, does it consider ruby?
fantasai: ?
glazou: why are we blocking this?
RESOLVED: add astearns, fantasai as editors to line-grid module,
published FPWD css-line-grid
dbaron: I'd like to see that wording thing fixed.
fantasai: ok I'll fix it
BREAK 15 minutes
CSS3 Color
----------
Scribe: sgalineau
chris: to discuss the state of implementation and test suite
fantasai: any testcases from anyone on currentColor?
dbaron: I think I added one for the new behavior...
<dbaron> I added contributors/mozilla/submitted/css3-transitions/currentcolor-animation-001.html
fantasai: currentColor used to compute to the value of color
fantasai: instead it now inherits
dbaron: the test I added for another behavior derived from this change,
namely animation implication
dbaron: you'd need to use currentColor on background and test its
inheritance
<dbaron> contributors/mozilla/submitted/css3-color/t44-currentcolor-inherited-c.xht
<dbaron> is a direct test for the erratum
<fantasai> http://test.csswg.org/shepherd/testcase/t44-currentcolor-inherited-c/name/t44-currentcolor-inherited-c/
chrisl: is this test waiting for review? I am happy to review
<fantasai> r=fantasai
SimonSapin: Servo should implement the new behavior, but I haven’t
tested it explicitly
ACTION chris Review dbaron's test
<trackbot> Created ACTION-610
<dbaron> http://test.csswg.org/shepherd/search/name/t44-currentColor/
<dbaron> the two plinss tests are for the old behavior
fantasai: does anyone implement the new behavior?
simonsapin: Servo...maybe?
fantasai: does any impl pass David's test?
<dbaron>
http://test.csswg.org/shepherd/repository/5af75de6ab2b85d4233bd429e9897820c28180b4/contributors/mozilla/submitted/css3-color/t44-currentcolor-inherited-c.xht
chris: Firefox does not.
Rossen: no pass in IE either
<smfr> no pass in WebKit
<SimonSapin> After changing the test to not use CDATA (we don’t
support XML), Servo passes the test
<SimonSapin> WeasyPrint passes too
Question of why the change.
fantasai: we needed current color for an inheritable property: text-emphasis
fantasai: we wanted the initial value to be something that said use
the current color
fantasai: so it was a matter of adding a new keyword or redefining
currentColor
fantasai: the change made no difference for current uses of the keyword
fantasai: so we were able to make the change even though it was incompatible
dirk: I don't think the SVG WG reached consensus
fantasai: if we don't want to make this change we need a different keyword
dbaron: in Gecko we have a second implementation of currentColor because
we can't use the old currentColor
SimonSapin: Servo and WeasyPrint pass this test
fantasai: anyone implement text-emphasis?
<crickets>
<tantek> I am ok with this change to currentColor
<tantek> this seems like a good improvement to currentColor
<fantasai> SimonSapin, do Servo and WeasyPrint both pass the entire
CSS3 Color test suite?
<SimonSapin> fantasai, I don’t know, since that suite is not automated
<SimonSapin> fantasai, they do pass color3*.json in
https://github.com/SimonSapin/css-parsing-tests , but
that’s only parsing
Received on Tuesday, 4 February 2014 09:11:48 UTC