W3C home > Mailing lists > Public > www-style@w3.org > January 2012

[CSSWG] Minutes and Resolutions Telecon 2012-01-11

From: fantasai <fantasai.lists@inkedblade.net>
Date: Fri, 13 Jan 2012 00:03:07 -0800
Message-ID: <4F0FE53B.30203@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
   Rossen Atanassov
   David Baron
   Kimberly Blessing
   Bert Bos
   Tantek Çelik
   Elika Etemad
   Simon Fraser
   Sylvain Galineau
   Daniel Glazman
   Koji Ishii
   John Jansen
   Peter Linss
   Edward O'Connor
   Anton Prowse
   Florian Rivoal
   Alan Stearns
   Daniel Weck

<RRSAgent> logging to http://www.w3.org/2012/01/11-css-irc
Scribe: fantasai


   Daniel: Happy New Year everyone!
   Daniel: Extra items?
   <Rossen> HNY Daniel!

Media Queries for Scriptability

   <glazou> http://lists.w3.org/Archives/Public/www-style/2012Jan/0034.html
   Daniel: Florian said he is willing to add that to the editor's draft
   Florian: I do not want to add that for L3, but when considering L4 I think
            this is interesting both on its own merits and as a general trend
            of what I'm thinking about
   Florian: Usefulness described in ML
   Florian: For L4, I was thinking to develop more media features
   Florian: Currently we detect print as a media type
   Florian: Doesn't work well because you can't be both print and screen
   Florian: But some devices share aspects of both
   Florian: Would be good to detect whether you are paged or not, screen
            can be refreshed or not,
   Florain: detect whether there is a touch screen
   Florian: This way can adapt layout for the device without knowing exactly
            what it is
   Daniel: Other opinions?
   fantasai: Sounds good to me
   <stearns> +1 florian
   <TabAtkins> +lots
   Kimberly: Certainly for Comcast devs, when we read the proposal, were very
             excited. A lot of interest amongst the dev community here
   <tantek> sounds good to me also. (add js detection to media queries 4)

   Anton: Someone mentioned NoScript on the mailing list
   Anton: Can choose to run script on some domain, not others
   Anton: Difficulty with CSS support statement that you either support script
          or you don't, not clear what it means
   Anton: If I allow base domain to run scripts, but not third-party domains
          to run scripts, what then?
   Florian: Haven't thought about that. Maybe we choose yes or no for some
            scripts. Or maybe we have a finer distinction
   <tantek> I don't think a URL check is necessary for the common case.
   <tantek> there are enough 3rd party script blockers that sites have to work
            without 3rd party scripts anyway

   Bert: Wondering if this opens a can of worms.
   Bert: Script is rather high level, but other things you could want
   Bert: Might need a way to control the vocabulary
   Bert: Something called CC/PP has a URL-based vocabulary and framework
   Bert: Let's use that
   Daniel: Is that implemented in browsers?
   Bert: Some mobile browsers

   Tantek: I think the 3rd party script case is, from dev standpoint, an edge
   Tantek: Rather than presenting as a problem, would like to know why we care?
   Tantek: I think the current use case stands well enough on its own.
   Tantek: Would consider case of third-party scripts being disabled as a
           separate use case.
   Florian: So if they're disabled, you would say scripting is supported?

   Tantek: I don't think any modern people care about CC/PP or know what it is.
   Tantek: And URL-based vocabularies have not been successful on the Web.
   Tantek: We can look at CC/PP cases one by one to find use cases
   Daniel: Not first time we discussed CC/PP, never succeeded in integrating
   Tantek: There's an opportunity for reuse of terminology, rather than
   Tantek: But I wouldn't expect any web developer to know or use it.
   * TabAtkins doesn't know what CC/PP is.
   * florianr doesn't know either
   <dstorey> *me neither*
   <arno> ccpp = composite capabilities/preferences profiles
   <arno> http://www.w3.org/Mobile/CCPP/
   Tantek: CC/PP was designed for previous generation of phones. Hasn't kept
           up with modern mobile web

   Anton: Modern scripts, when they are working with CSS, because there is
          no syntactic support for using script, what they tend to do is to
          insert a class into the <body> tag
   Anton: And usually that class name is specific to the script, that is if
          it's a library, it inserts the library name into the <body> tag.
   Anton: In the CSS you can distinguish which libraries are loaded from the
   Anton: What we're seeing with this proposal is that we're losing that
          fine-grained control, and to me that feels a little bit of a step
   glazou: So you are saying that because the feature is not powerful enough,
           moving it to declarative is not a good idea.
   Anton gives an exampe.
   Anton: Until we have some concrete uses -- what exactly would someone be
          styling differently based on script or no script? -- we are going
          to get worse-written websites.
   Tantek: One of the popular libraries right now, modernizr, specifically
           provides devs with JS and No-JS class names
   Tantek: Since there's a modern library that provides this, that people use,
           shows that there's a use case for coarse granularity.
   Tantek: Not saying there isn't a case for fine granularity, but that coarse
           granularity has a strong one.
   <tantek> see http://www.modernizr.com/docs/
   <tantek> specifically, Modernizr replaces the class of "no-js" in the HTML
            tag, with "js" when JavaScript is present
   Daniel: I have a use case for editors, where JS is disabled by default;
           editing a dynamic document makes no sense.

   Florian: I suggest we start drafting the coarse granularity version
   Florian: and then go further if we see the need.
   Daniel: Since I see no objection to the original proposal, I say we go ahead
           and add that. Possibly add a note about finer granularity
   <dbaron> I think the key question is what percentage of the use cases for
            this a (script) media query would solve, and what percentage
            would need more detailed domain or script-feature support.
   Florian: So far don't have an editor's draft, will put in the wiki
   dbaron: Just wanted to comment that, one thing I'm more worried about than
           domain stuff, is how much people are going to want the detection to
           be based on particular features in the script
   Florian: Once you know script is running, you can do feature-detection in
            the script.
   dbaron: Question is, what is the percentage of use-cases that want
           feature-detection vs. scriptability detection.
   dbaron: If that percentage is high, then we are not solving the real problem.
   <tantek> dbaron, but this is a replacement for what modernizr does
   <tantek> modernizr replaces "no-js" with "js"
   <tantek> and developers style based on that
   Florian: Having more concrete use cases would help figure this out.
   RESOLVED: Draft script/no-script detection for Media Queries 4

Publish CSS3 Text / CSS3 Writing Modes

   Daniel: jdaggett says he's fine with publishing css3-text, but would like
           to defer decision to publish css3-writing-modes to next week
   Daniel: Anyone else?
   Daniel: No objection to publishing CSS3 Text?
   Florian: not from me
   RESOLVED: Publish CSS3 Text as WD
   Writing Modes deferred to next week

Switching to Mercurial for specs

   <smfr> yes please
   <tantek> what about git?
   <TabAtkins> +1
   <TabAtkins> git's my preference, but anything is better than CVS.
   * sylvaing doesn't mind CVS as much as the SSH voodoo
   <sylvaing> but no objection to using something that's younger than me
   * tantek doesn't mind CVS either

   Bert: Explain the advantages?
   Florian: nicer to work offline, diffs are easier, merging is better
   <sylvaing> if merging is better, that's big imo
   fantasai: We can rename and move files, and fork them while keeping history
   fantasai: which we're doing a lot when splitting things into two levels
   fantasai: We don't really do any merging, so I don't see that as an
             advantage here.
   Tantek: Consider others like git?

   * sylvaing really wishes specs were edited inline, wiki-style....
   plinss: Considering that we're using Mercurial for tests, and others
           are W3C are using it for both tests and specs
   plinss: Don't see the advantage to using git
   <arronei> I agree I don't see andy reason for using git.
   <arronei> Mercurial seems to be the common one at W3C
   Tantek: I don't want to switch to another system without at least having
           parity with CVS on documentation for setting up to edit
   <sylvaing> agrees with Tantek
   Tantek: "if it's not broken don't fix it" consideration...
   <dbaron> http://hgbook.red-bean.com/ should be a good starting point
   <plinss> http://wiki.csswg.org/test/mercurial
   <dbaron> http://annevankesteren.nl/2010/08/w3c-mercurial
   Kimberly: There's some very good documentation online for Mercurial,
             they used at TPAC for people starting to write tests. With
             that documentation, I was up and running in 3 minutes
   Tantek: Woah
   <glazou> ROFL @ "the rest is relatively easy. Just invoke hg. "
   <dbaron> http://www.w3.org/html/wg/wiki/Testing/Submission/
   <sylvaing> there is source control doc, and there is the connectivity
              part e.g. SSH. I had a far harder time setting up the latter
              than the former

   Florian: Are we importing history from CVS?
   fantasai and dbaron explain this is straightforward to do
   <dbaron> Are we planning one repository per spec or one repository for
            all specs?
   Tantek: I want to see documentation at the same level as the CVS
           documentation we have first.
   sylvain agrees
   <TabAtkins> I think current practice is to do one repo per spec?
   <TabAtkins> One problem I have with the W3C's Hg - it's basically
               impossible to find the damned spec in the view.
   <TabAtkins> Our CVS view is easy - just go to dev.w3.org/csswg

   <tantek> frankly, mercurial is already legacy. open source communities
            have moved onto git.
   Tantek: Another concern is that Mercurial is already legacy outside of W3C
   Tantek: New projects use github, people use git
   Daniel: This does not sound like a good argument time. Geeks are going to
           use the newest best thing.
   Florian: For a while it was not clear whether Mercurial or Git was better,
            now more people prefer Git.
   Florian: While I prefer Git, we are using mercurial throughout W3C, so I
            don't mind ..
   <arno> git does have a lot of wind in its sails
   Tantek: I am skeptical about switching to Mercurial and then in a few years
           switching to git
   plinss: There's a lot of cost to us using Git, and W3C using mercurial.
   plinss: Even assuming W3C eventually switches to git.
   <dstorey> main advantage for me with git is using github over say bitbucket,
             but I guess w3c will be self hosting rather than on github
   <Bert> q+ to ask if we can first ask other WGs for their mercurial experience
          (don't like to be the first to use a new tool...)
   Florian: How many W3C tools, rather than W3C people, rely on Mercurial?
   plinss: test suite tools, as well as actual usage
   fantasai: A lot of the systems plinss has been building for testing are
             integrated with mercurial
   tantek: People are building tools on top of git, not so much on top of
   tantek: it's a dying platform
   plinss: I don't agree it's a dying platform, and a potential move years in
           the future
   <kojiishi> There seems to be a lot of W3C repositories already at
   <Bert> -> http://www.w3.org/blog/systeam/2010/06/16/why_we_chose_mercurial_as_our_dvcs/
          W3C systems team on Mercurial vs others

   Daniel: I'm hearing no consensus.
   Florian: What I'm hearing is ppl who are pushing for hg, write CSSWG-specific
            documentation for it.
   <sylvaing> I have no opinion on moving out of CVS. But if someone writes a
              doc to switch, I'll test it out and volunteer to document the
              Windows steps
   Florian: If it's good enough for the skeptics, then we can move.

   <dbaron> I'm not sure the conversion is all that straightforward -- I think
            conversions from CVS are pretty painful no matter what.
   <dbaron> (conversions of existing history, that is)
   <sylvaing> dbaron, isn't that true of any source control system migration?
   <dbaron> sylvaing, I think conversions between systems that use atomic
            commits are a lot easier.
   <sylvaing> dbaron, fair.
   <dbaron> sylvaing, though conversions between svn and others are a little
            painful because of its use of conventions for branching/tagging
            instead of mechanisms

   Daniel: who is willing to take an action on writing that documentation?
   Daniel: Mercurial is very powerful, but it is much harder to understand.
   Koji: I thought Anne said documentation is already available for HTML
         group, isn't that enough for us?
   <kojiishi> http://annevankesteren.nl/2010/08/w3c-mercurial
   <tantek> here is the challenge, if you support mercurial, write up
            documentation *at least as good as*  http://wiki.csswg.org/spec/cvs
   <tantek> previous to that cvs documentation there were *tons* of cvs
            documentation on the web and yet it was still a huge barrier for
            editors of CSS drafts
   <Ms2ger> I would love to see that for git
   * glazou is suprised nobody mentioned svn as an alternative :-)
   <tantek> so no, external mercurial documentation is insufficient
   <dbaron> tantek, I expect the hg version of that will be a lot shorter
   <dbaron> tantek, because there's no ssh involved (w3c setup uses https:)
   <tantek> if you want to switch to mercurial, put in the work to provide
            AS GOOD documentation as CVS
   <tantek> if you don't have the time for that, then neither should the
            rest of the group

   fantasai explains reasoning for opening the discussion: at this point,
   Mercurial has gained traction at W3C, and we're starting to do a lot
   of spec forking with the level splits etc, and more renaming as well
   as we start new modules.

   sylvaing: We need a volunteer to write a doc, one to write steps for
             Windows, and volunteers to test it.
   Florian: I'll volunteer to test it; I'm in favor of switching.
   <dbaron> can we agree to put said document at http://wiki.csswg.org/spec/hg ?
   <fantasai> yes
   * fantasai notes there's probably some docs in the testing section, too
   Daniel: Still need volunteers to write docs

EXIF orientation for images

   dbaron: There are ppl who want to post images that get their EXIF
           orientation handled by the browser. Since it's not backwards
           compat, can't do it by default.
   * tantek really wants this as a web author
   dbaron: Thought we had one in an old draft, but maybe I'm misremembering.
   fantasai: This would probably be image-orientation property, which never
             got an auto keyword.
   <TabAtkins> I wouldn't mind changing image-orientation's grammar to
               "[ <angle> || flip ] | from-image"
   <tantek> or image-orientation: exif ?
   <tantek> why not be specific and say exif rather than auto?
   <fantasai> tantek, because it might be doen via some other technology
              in some other image format
   <fantasai> CSS keywords are format-agnostic

   dbaron: Question is, do we want to do this, and if so do we want
           image-orientation to support all EXIF orientations rather
           than just the 4 it now supports
   Florian: Does anyone use the other orientations?
   Arno: It's in the spec, but I can't think of any camera that uses them.
   <TabAtkins> The extra 4 orientations are used sometimes for self-facing
   <TabAtkins> vs world-facing
   <TabAtkins> Note as well that Chrome would like to implement auto-orienting as well.

   <tantek> analogy: color-profiles
   Tantek: Some images have embedded color profiles, we never got to using those.
   Tantek: We dropped that property due to insufficient interest.
   Tantek: Just wanted to point out similar situation.
   Florian: One problem was mismatched colors between flash and images.
            But Flash now does it

   fantasai: I think it's a fine idea, my concern is whether it should go in
             L3 or not
   fantasai: if it's L3, I need a final proposal today so I can put it into
             the LC that's being published tomorrow
   <tantek> level 4

   <smfr> http://www.w3.org/TR/css3-images/#image-orientation0
   smfr: I've seen patches come in that attempt to support this.
   smfr: Question is, does this only affect content images, or also CSS images?
   <TabAtkins> smfr: image-orientation only affects image elements.
   <TabAtkins> It's... kinda underdefined right now.
   Florian: Intuitively, I'd say only content images
   <TabAtkins> Theoretically it could affect <video> and <canvas> too, I guess.
   fantasai: content images can be injected via CSS, too. Also image-resolution
             IIRC applies to CSS images as well
   <tantek> hence why I said level 4 ;)
   Daniel: Let's explore this idea.
   <TabAtkins> image-resolution is currently defined on all elements, but
               that's inconsistent and weird.
   <TabAtkins> image() previously allowed resolution-altering on specific CSS
               images, which I think is a better thing.
   fantasai: image-orientation is in the draft because printer implementations
             needed it; that's why we need to take this feature set to level 3.
   Florian: Can we add a note that CSS4 will add EXIF support?
   fantasai: sure

   Topic: Publish CSS3 UI as LC
   <tantek> anything stopping http://dev.w3.org/csswg/css3-ui/ from being
            published as LC?
   Tantek: Checked in changes requested
   Tantek: Didn't hear any feedback or objections in the last week
   Tantek: So what's the next step?
   Florian: I asked for a week review last week, and didn't find time,
            so I'll just shut up
   Tantek: if you want a day, I'm fine with that.
   Florian: Don't have time, so I will just trust other people to review.
   Tantek: How long do people want the last call?
   discussion of when to set the deadline
   <Bert> (3 weeks is required)
   Daniel: I recommend 4 weeks
   fantasai: Working Groups to contact?
   Tantek: HTML
   Tantek: WAI-PF
   Tantek: SVG?
   Bert: XForms
   <tantek> Bert if there are any problems with publication of the LC (like
            any details I have forgotten), please let me know!
   <tantek> I will be on irc and try to be very accessible to help out
   RESOLVED: Publish LC of CSS3 UI with 4 weeks comment period
   <fantasai> tantek, make sure you run the validator and the link checker first
   Tantek: If anyone has any other issues or typos to report, send them in.

Meeting closed.

<dbaron> I started sketching out http://wiki.csswg.org/spec/hg but it needs some more work
Received on Friday, 13 January 2012 08:03:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:09 UTC