W3C home > Mailing lists > Public > www-style@w3.org > February 2014

[CSSWG] Minutes Seattle F2F Tue 2014-01-28 AM I: Media Queries, Baseline Grids, currentColor

From: fantasai <fantasai.lists@inkedblade.net>
Date: Tue, 04 Feb 2014 01:11:16 -0800
Message-ID: <52F0AEB4.6000804@inkedblade.net>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 4 February 2014 09:11:48 UTC