- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 10 Jul 2014 11:28:43 -0400
- To: www-style@w3.org
Upcoming F2F
------------
- Bert informed the group that he has begun the wiki for the next
F2F and encouraged people to add their names if they know
they'll be attending.
Exposing Color Parsing
----------------------
- There was general support for TabAtkins's proposal and he'll add
it to Color 4.
Extrinsic Sizing of Controls
----------------------------
- It was agreed that the issue raised by gregwhitworth was a bug
in implementations, not an issue with the spec.
CSS Ruby
--------
- fantasai updated the group on her status with Ruby and is
anticipating feedback from Kawabata and more conversations
with Boris.
Grid Layout
-----------
- fantasai outlined her current proposal for simplifying grid
layout error handling.
- There was general approval from the group.
- She will seek a resolution next week after Rossen has had time
to review the proposal in more detail.
Flexbox Update
--------------
- At Rossen's request, fantasai also gave an update on Flexbox
- She said she was close to a complete DoC with only a few issues
that still need to be solved.
Korean vs Japanese Justification
--------------------------------
- In general, the group felt that authors should be encouraged to
language-tag their work to help avoid problems with the
behavior of auto.
- Since many documents aren't language tagged, everyone also felt
a solution did need to be developed. Suggestions included:
- Re-instituting the inter-character property
- Accepting that using auto limits some features and thus
encouraging language-tagging
- Creating a way to auto-detect the dominant script
- The discussion will head back to the mailing list for further
feedback and hopefully a good compromise on default behavior.
CSS Background Issue
--------------------
- Everyone agreed that the current behavior of display: none and
visibility: hidden is correct and should be written into a
spec.
- SimonSapin will come up with proposed text for an errata to
CSS 2.1 that the group can ratify.
===== FULL MINUTES BELOW ======
Present:
Glenn Adams
Rossen Atanassov
Tab Atkins (IRC Only)
David Baron
Adenilson Cavalcanti
Dave Cramer
Alex Critchfield
Elika Etemad
Sylvain Galineau
Koji Ishii
Dael Jackson
Brian Kardell
Taichi Kawabata
Philippe Le Hégaret
Peter Linss
Michael Miller
Shinyu Murakami
Edward O'Connor
Matt Rakow
Simon Sapin
Alan Stearns
Greg Whitworth
Steve Zilles
Regrets:
Bruno de Oliveira Abinader
Anton Prowse
Florian Rivoal
Dirk Schulze
Lea Verou
Scribe: dael
plinss: Let's start. Hello everyone. Is there anything to add to
the agenda?
<fantasai> http://lists.w3.org/Archives/Public/www-style/2014Jul/0137.html
fantasai: There was a message from SimonSapin on CSS-background
that seems straightforward (link above). If we have time
we can look at that.
bkardell: I don't have anything, but I was wondering what the
policy was on order. The last item is what I'm
interested in and I have to leave early. Any way to
shuffle the order?
plinss: We can certainly shuffle, but TabAtkins_ is the one that
mentioned it and he's not here.
bkardell_: We can maybe do it next week.
<TabAtkins_> What's that last item? In the car now, so I can talk
for a bit in irc.
<fantasai> color parsing
<TabAtkins_> Kk. Of your okay with me being irc-only, I can talk.
<TabAtkins_> Also I'm on a phone keyboard.
Upcoming F2F
------------
bert: We started the prep for food and stuff, the room is reserved.
bert: I made the page on the wiki with registration information.
Please fill in your name. The name is needed for network
access, so it's important.
bert: I put a few hotels around here, but you might want to look
in surrounding towns. I don't know if people want rental
cars, but you can maybe set up carpools .
bert: If you have any information to share, use the wiki. Or add
topics for discussion.
bert: That's all I had to announce. Were there any questions?
bkardell_: No question, but thanks for putting it together.
<sylvaing__> is there a wiki page for this meeting?
<TabAtkins_> Yes.
<Bert_> http://wiki.csswg.org/planning/sophia-2014
<sylvaing__> Ah, the page is not yet linked from the meeting
planning page
bert: The page still has holes to be filled in, but there's some
information already.
plinss: Thanks.
plinss: It looks like TabAtkins_ is on IRC so lets move the order.
Exposing Color Parsing
----------------------
<plinss> http://lists.w3.org/Archives/Public/www-style/2014Jul/0106.html
plinss: TabAtkins_ sent this in about exposing some functions for
color parsing. bkardell_ you said you were interested, do
you want to speak?
bkardell_: He said in his e-mail he was planning on looking at
deeper integration with CSS OM and I was curious what
exactly this might initial.
bkardell_: According to this you can make your own color format
and that means you could express color formats in ways
that were reflected in CSS or weren't but what form
would they stringify...
bkardell_: It may be difficult with just IRC.
<TabAtkins_> Ah, the "deeper integration" is what I talked about
at the January f2f.
<TabAtkins_> The JS Value Objects-based proposal.
<TabAtkins_> But that's still blocked on JS, so no need to worry
about that for now.
plinss: I presume with your own format it's just stringify and
parsing and you'd get a POC format that you could assign
directly.
<TabAtkins_> Yup, plinss. "var x = RGBAColor.fromMySpecialColor
(foo, bar); el.style.color = x; /* stringifies to an
rgba() function automatically */"
<sylvaing__> TabAtkins, what are 'foo' 'bar'
<TabAtkins_> sylvaing__: Whatever you want - that's an author-
defined function.
plinss: Since TabAtkins_ is only partly here, any other opinions?
plinss: Is this worth pursuing?
SimonSapin: There's 2 things here. One is exposing the parsing of
CSS color from a string to RGB numbers and I think
that's fine.
SimonSapin: The new color format, that's adding support for things
that would be added in style sheets.
bkardell_: The proposal includes both. It says authors can define
their own color format by adding to RGB with
appropriate color tags. If we're talking about the
proposal that's part of it.
<TabAtkins_> They explicitly did "RGBAColor.prototype.
fromMySpecialColor = function(foo, bar) { ... };"
<TabAtkins_> Sorry, scratch the ".prototype".
plinss: I don't presume those color caps would be embeddable raw
unless we really open parsing. This is only for authors
programatically for whatever IO format, they can modify
style sheets, but not add this as CSS source.
bkardell_: It seems that if you did this from the prospective of
serialization type, is it worth being able to
differentiate browser native and user defined?
plinss: I'm not sure you'd need to. We have serialization for
color so if you do an entire stylesheet it would go back
to RGB. It wouldn't attempt another model because they
style sheet wouldn't know what that format is.
<TabAtkins_> bkardell_: I am *not* talking about extending CSS
itself (yet). This proposal is just to produce a
Color object that has the right hooks that authors
can use it for their own needs, beyond just CSS.
<TabAtkins_> (Actually extending CSS for new color types will wait
for custom functions.)
<sgalineau> TabAtkins: ah, check. I thought you were describing a
proposal, not a practice
<bkardell_> tabatkins: I'm wondering really if RGBAColor.
serializationTypes would differentiate an author
defined serializationType, for example
<TabAtkins_> bkardell_: It doesn't differentiate, no.
<TabAtkins_> bkardell_: But the default serializer is rgba(), and
having the ability to serialize is distinct from the
ability to parse.
<TabAtkins_> bkardell_: Like I said, in the future custom
functions should take care of actually extending CSS.
For example:
<TabAtkins_> Eh, don't wanna write out an example right now. It'll
look something like the Custom Pseudo-classes bit.
<bkardell_> TabAtkins_: Yeah, it was mainly about is there utility
in being able to thinking about future proposals...
maybe I'll comment privately || on ML
plinss: Other opinions?
SimonSapin: Sounds good. Let's do it.
plinss: I'm not hearing objections. Let's accept the proposal and
add it to CSS Color 4 or the OM as appropriate.
<TabAtkins_> Okay, I was going to ask what spec to put it in.
Color works. ^_^
Extrinsic Sizing of Controls
----------------------------
fantasai: I was looking at the e-mail, I don't think you meant
extrinsic, I think you meant explicit.
gregwhitworth: I'm referring to exterior width. I know vendors get
antsy about what's on the interior.
fantasai: So extrinsic isn't the word. I think this is in CSS2.1
where we spec where the scrollbar goes and takes room.
It's not super clear but it spec the Firefox behavior
fantasai: Here's the response.
<fantasai> http://lists.w3.org/Archives/Public/www-style/2014Jul/0143.html
rossen: For all I know we have a bug there for not taking
scrollbar out of min-width
fantasai: Min-width and width shouldn't be different.
rossen: I agree. I don't think 2.1 has text for that, but I agree
the intent is they should be the same.
fantasai: They're defined as equivalent in their effects.
rossen: Scroll-bar size is taken out of use width.
fantasai: min-width effects the content box, but we take out the
scrollbar once you form a containing block. So the
content inside is in a smaller box.
rossen: I think gregwhitworth's example shows issues with IE and
Chrome. Other than that I don't think we need spec changes.
rossen: Unless gregwhitworth thinks otherwise.
gregwhitworth: I wanted to make sure we're on the same page.
rossen: The point is valid, we should converge. I think the spec
is clear and we need to fix bugs.
rossen: Anything else on this?
gregwhitworth: Nope.
fantasai: Nope. If we want to clarify 2.1 we can.
CSS Ruby
--------
fantasai: The update is that we've been working on the box model,
particularly anonymous box.
fantasai: I've been doing that on the list. Mozilla is
implementing the rules so we're getting good feedback.
fantasai: My goal is to get Boris to agree the rules are correct
and than get a new WD. There is stuff with Ruby layout I
haven't drafted.
fantasai: We've also defined white space by making anonymous boxes
that are similar to existing, but they don't pair. If
there's pairs, they get paired with anon boxes in
another layer
fantasai: For nested I'm trying to handle with layout rules rather
then trying something fancy in box generation.
fantasai: That's the overview. If there's interest I can do more
details.
plinss: Okay. No questions?
plinss: I know everyone is excited about Ruby
fantasai: Is there anyone that wants to review that I should wait
for feedback? .
<kawabata> I'll check it closely.
fantasai: Okay. I'll wrap up edits with Boris and get a check from
kawabata-san.
<gregwhitworth> fantasai: I do think extrinsic is the correct term
per the sizing spec as I don't want controls
dimensions to be determined by the contents if
stated the the author .
Grid Layout
-----------
rossen: I was in and out and couldn't review.
rossen: I got fantasai's e-mail, but I'm just not ready. If we
want to make a decision I'd ask to postpone. If this is
just an awareness thing, that's fine. But if you want
consensus, I'd prefer we do this next week.
fantasai: I'll explain, but not resolve.
fantasai: For Grid we have 2 properties in any dimension. There's
grid column start and end. These can be number of lines
or a span of this many lines or names lines.
fantasai: We have error handling. If you specify, for say, a line
that doesn't exist. Or a different case if you're
spanning for 5 lines and there's only 4. We had various
rules for different cases for what if you don't have
enough.
fantasai: What we did was we realized we could have a simple rule
that says there's an explicit grid and that's the one
you set up. There's also an implicit grid where if you
position an item with numbers such that it's no longer
in that explicit grid, they're still in that implicit
grid.
fantasai: We decided we could simplify by saying if you can't find
a named line, assume that the implicit grid has those
lines and count in there. It's simple and consistent.
fantasai: It can give you odd results, but that's good because it
gives you things that are noticeably off.
fantasai: Those are the main advantages of this new set of rules.
We're looking for review from anyone with an opinion.
rossen: I don't see anything wrong with the approach, I have to
sit down and work through the cases and see if this is
sufficient.
rossen: If it is, I'm fine.
fantasai: If you're interested, send your comments. Otherwise well
close the issue with rossen's opinion next week.
plinss: It sounds like a reasonable approach. Any times there's an
error the author won't get it. I think this is as good as
we'll get.
rossen: It'd be better to keep the error as dominant and simple as
possible. We don't want to "help" them too much. We want
it to be outrageous so that it's obviously an error. Let
me sit down and I'll have a better opinion next time.
fantasai: Because we have a rule with just numbers and not names,
if you say 7th and there's only 5, we create a 7th.
fantasai: If you think of named lines creating an implicit grid,
we just do the name thing. We add named lines until you
have the right number.
plinss: The problem is if people are adding named, there's likely
a pattern and the author will expect a pattern, but I
don't think we want to create an algorithm for that.
rossen: I agree, especially in the error case.
rossen: It makes sense.
fantasai: Yep.
Flexbox Update
--------------
rossen: While we're on grid, related question. Do we have anything
for flex box? Where do we stand?
fantasai: We fixed a bunch of issues. A lot was responses to the
changes. Some comments were other noticed errors.
fantasai: There's 2 issues that aren't quite sorted.
<fantasai> http://dev.w3.org/csswg/css-flexbox/issues-lc-20140325
fantasai: Here's the DoC.
fantasai: We have an open issue on intrinsic aspect ratio items
and minimum sizing.
<fantasai> http://dev.w3.org/csswg/css-flexbox/issues-lc-20140325#issue-19
<fantasai> http://dev.w3.org/csswg/css-flexbox/issues-lc-20140325#issue-16
fantasai: There was a couple we fixed and need review, I think
issue 19. 16 is open. And then static position stuff we
haven't sorted.
rossen: For the auto position abspos?
fantasai: Yeah. That's issue 12.
<fantasai> http://dev.w3.org/csswg/css-flexbox/issues-lc-20140325#issue-12
rossen: Okay.
rossen: It doesn't sound far from done.
fantasai: It's those three things to look through. 16 and 19 need
the most review because they're confusing issues.
fantasai: I think 16 has comments from dholbert.
fantasai: Once we're through those we'll have a complete DoC to
review with the WG and do a new LC. We really appreciate
comments because there's a lot of tricky things
rossen: Thanks. Sorry to hijack the agenda
Korean vs Japanese Justification
--------------------------------
fantasai: koji is trying to get comments from the Korean community.
fantasai: There are Japanese and Chinese docs that are formatted
similarly. Korean isn't though. Most modern docs are in
Hangul, but some have Chinese characters.
fantasai: So Chinese characters are a part of Korean, but not
common. Korean does have spaces and uses spaces to just
like Latin languages.
fantasai: Chinese and Japanese don't use spaces to justify. What
happens in a line of Japanese, you'll have only 0 or 1
space and if you use spaces to justify you'd have huge
spaces. Instead you space between characters.
fantasai: This has created a problem between Korean and Japanese
documents where just Korean wants to use the spaces to
justify.
fantasai: I think one browser spaces between Chinese and Japanese,
but not Hangul which creates some problems with mixed-
script text. We're looking for a compromise that's
appropriate for untagged content. If it's language
tagged you're fine, but when it's untagged that's what
we're stuck on. While the spec won't require anything,
we wanted to have a suggestion.
SteveZ: Question. Clearly the existence of either Hangul or the
various kana in Japanese gives you a hint of the language,
but that requires pre-scanning.
fantasai: So far we're tried to avoid heuristic detection. If we
built that in it would be a significant paradigm shift.
fantasai: We're trying to avoid heuristics and only rely on tags
and properties.
SimonSapin: Would it make sense to look at language?
fantasai: This is when a language tag isn't present.
SteveZ: Anyone looking at the page could tell you what language.
It'll seem strange to the user that they system can't
fantasai: If the WG wants to go that route we can. I think there
was a text-script property before where you auto-detect
the dominant script and if it's wrong you can tag, but
so far we've avoided auto-detection.
dbaron: I'd rather encourage people to language-tag their content
correctly.
<bkardell_> +1 to dbaron's comment
<SimonSapin> +1 dbaron
SteveZ: I think...I agree that having tagging on something is the
best way to go, but we've already learned people copy from
others and do the minimum to get it to look right and I
think browsers in Korea may get tuned to make a Korean
assumption and it works if you don't take it out of the
context.
fantasai: I think that used to be true, but no longer.
SteveZ: You think authors are tagging?
fantasai: I think browsers aren't shipping biased engines of
layout versions.
SteveZ: It's not much of a bias to say assume Korean.
fantasai: It's still a bias.
bkardell_: There's language setting in the OS.
fantasai: We don't use the OS because it would make our page look
different depending on what computer you're looking at.
We want to depend only on page content.
SimonSapin: Firefox has a character encoding fallback based on the
local of the user. That's legacy content and I don't
think we should add a new behavior.
plinss: I agree. If we want to encourage authors we can define the
default as the worst behavior.
dbaron: There's enough pages without language tags that we can't
do something horrible, but we can do something like make
hyphenation not work.
<bkardell_> this doesn't seem horrible if there is no way to tell.
fantasai: So we can make spacing look not optimal, but that's the
worst.
SteveZ: So is plinss suggesting something that doesn't work in
either case and dbaron says that's not an option?
fantasai: I think dbaron is saying don't break stuff, but you
won't get the best behavior if you don't language-tag.
plinss: I was trying to encourage authors to language-tag, which
means as little magic and markup as possible.
??: Can you treat justification so it doesn't work without
language tagging?
fantasai: I think the default should be better than now where it
doesn't work for CJK and does for Latin. We can't make
it worse than it is. All space separated languages work
now.
SteveZ: If the current state is it doesn't work for non-space-
separated languages we can leave it to make people tag.
fantasai: We dropped the inter-character value and there's a bunch
of pages that currently spec using inter-character, but
since we dropped that and assumed auto would handle it,
we have to make sure auto does.
SteveZ: This sounds like a problem we made.
fantasai: A bit. But I don't think Firefox supports it so it's not
completely us.
SteveZ: We dropped inter-character because?
fantasai: The argument was auto should be able to do it. We have a
couple of solutions that approximate the right thing,
but not quite perfectly. The discussion is, of the
possible compromises, what's the best one?
SteveZ: I haven't thought about it a lot, it seems inter-character
should come back.
fantasai: Inter-character isn't needed if you language-tag
correctly, but people are using inter-character to fix
their layout, their pages.
glenn: They didn't understand the effects of language tagging.
fantasai: Yeah.
koji: I think I'm tending toward inter-character, but I'm awaiting
the replies from Korean community. There's a possibility we
want it back.
koji: It may be correct or not, but we need a little more
distinction.
plinss: It sounds like we loop back with more feedback.
fantasai: If there's ideas for a compromise for default rendering,
please comment on the thread.
CSS Background Issue
--------------------
SimonSapin: It's about backgrounds of the canvas.
SimonSapin: What happens if we specify display: none or
visibility: hidden. It's not clear in the spec what
should happen, but we have strong interop that the
background is still shown with display: none, but not
with visibility: hidden.
dbaron: There's a test case Hixie wrote a while ago. There was one
for display: none and filed it as a bug against all the
browsers.
SimonSapin: We should have a corresponding statement in the spec.
dbaron: Sure.
<MaRakow> Do you happen to have a link to that test case?
plinss: Okay. Everyone agree?
Rossen_: Any reference to the test cases?
<SimonSapin> http://lists.w3.org/Archives/Public/www-style/2014Jul/0137.html
SimonSapin: Here's the link with simple test cases.
fantasai: I don't have much opinion, but whatever we do should be
consistent with how we do writing mode direction and
overflow propagation.
plinss: If you're in a display: none situation, will any of the
properties have an effect?
plinss: All you'd draw is a canvas
fantasai: You can detect overflow: scroll and that might have an
effect depending on implementation.
SimonSapin: Do we only get writing mode direction from the root
element?
Rossen_: I think for IE we always propagate from body or HTML.
Rossen_: We treat it the same way to the root element which HTML
spec says that we take those and leave body so it has a
chance to redefine for overflow or writing. If HTML
doesn't have it we take it from body.
SimonSapin: The spec says don't do that.
Rossen_: Which?
<SimonSapin> http://dev.w3.org/csswg/css-writing-modes/#direction
SimonSapin: Link above
<SimonSapin> "Note that the direction property of the HTML BODY
element is not propagated to the viewport. That
special behavior only applies to the background and
overflow properties."
Rossen_: That spec was written 5 years after we did that
implementation. Maybe it now says something different,
but that's what we do.
Rossen_: It's interesting that it deviates from how we handle
overflow. I would expect the same.
fantasai: We had a legacy constraint that we were hoping wasn't
there for direction.
fantasai: We wanted authors to tag the root.
Rossen_: If you haven't implemented writing-mode, maybe. If you've
had it for a long time then you have an issue and if you
write ignoring that, you can avoid the issue.
fantasai: This is direction. It's been around since the 90's.
fantasai: Everyone's implemented it.
Rossen_: Right.
<plh> (fyi: the note was including in the FPWD of writing modes
back in 2010, but it's not part of CSS2.1)
plinss: Any conclusions?
SimonSapin: For writing-mode and direction properties this
propagation only applies to principal writing mode
which is only used for paged media.
<SimonSapin> http://dev.w3.org/csswg/css-writing-modes/#principal-writing-mode
Rossen_: Would you expect different for regions?
fantasai: Regions wouldn't need principal writing mode. It has its
own thing.
plinss: We're low on time and should wrap up. I think we agree we
want to spec current behaviors, at least for background
properties. Where is that?
fantasai: Backgrounds and borders 3.
plinss: not 2.1 errata?
fantasai: We could do that.
Rossen_: 2.1 errata would be nice.
plinss: So we'll call it 2.1 errata
<plh> is it possible to have a test case for this erratum?
fantasai: Bert, can you do that?
bert: I can if I know the text. What is it?
fantasai: SimonSapin can you write one?
SimonSapin: Okay.
fantasai: SimonSapin will write proposed text, we can ratify it,
and you can make the errata.
plinss: Anything we want to do with propagation of the other
properties, or leave it for now?
Rossen_: Let's do it separately.
plinss: Okay.
plinss: That's the end of the hour and the agenda. Thanks everyone
and we'll talk again next week.
Received on Thursday, 10 July 2014 15:29:10 UTC