- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Fri, 13 Jan 2012 00:03:07 -0800
- To: "www-style@w3.org" <www-style@w3.org>
Present:
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
Administrative
--------------
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
case
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
reinvention.
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
CSS.
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
backward.
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
Mercurial
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
http://dvcs.w3.org/hg
<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
cameras.
<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