- From: Dael Jackson <daelcss@gmail.com>
- Date: Fri, 2 Jan 2015 09:53:53 -0500
- To: www-style@w3.org
Text
----
- RESOLVED: Layout methods should depend on writing system in
addition to language convention
Selections
----------
- RESOLVED: Two-value text-overflow is line-left and line-right.
Counter Styles
--------------
- RESOLVED: Add to Counter Styles the additional styles supported
by 2+ browsers (per r12a's email), do not add the styles
supported by only one browser
- RESOLVED: Take counter styles to CR and go to the new process if
we can
- RESOLVED: minimum of 3 months for counter styles CR
===== FULL MINUTES BELOW ======
Scribe: dael
Text
====
fantasai: Let me pull up notes. The main issue was the
justification where I'd want koji.
fantasai: Other stuff is, as I was cleaning the handling of
Korean, I noticed we have text saying justification
method depends on language conventions. We need to have
it say writing system and language convention.
fantasai: Many languages can be written in multiple writing
systems. The correct layout isn't only language-
dependent.
fantasai: Mongolian, Japanese, Turkish can be written in multiple
writing systems. Correct layout depends primarily on the
writing system: minor things vary by language within a
writing system, but major things vary when you change
systems.
fantasai: So if anyone has comments or concerns about that let me
know, if not I'll take a resolution to update the spec.
murakami: For Korean and Hangul, all the text didn't have word
spacing. and it's not sufficient to distinguish modern
and older Hangul text. And the language attr cannot be
used. I think the text justify property is needed for
distinguishing modern and older style Hangul.
fantasai: I think old style Hangul is only Hangul, correct? It
doesn't include Latin?
murakami: I don't think too much Hangul, but I think the word text
was used in 1896. Before then, Hangul text did not have
word spacing.
fantasai: If the text does not include Latin, then inter-character
is sufficient. If we need to worry about Latin, we need
inter-ideographic.
murakami: I think it's needed.
fantasai: I think for right now it's enough of an edge case we
should address it in the next level. In general it can
be worked around with an inter-character value unless
it's mixed script. In that case we'd need to look at
reintroducing inter-ideograph
murakami: Inter-character isn't good for old Hangul. The Latin
letters may be included in all Hangul text.
TabAtkins: Is there much old Hangul on the web?
murakami: I don't know very much, but some examples I posted on
the mailing list.
murakami: Not I. Someone else posted.
fantasai: I think someone said they were wrong.
TabAtkins: The KL examples were pretty wrong.
fantasai: I don't have a strong opinion, but I think jdaggett does.
I think we should take justification up when he calls
later today.
fantasai: I think we should come back to this and resolve on
effects being writing system and language dependent.
fantasai: Any concerns with that issue?
RESOLVED: Layout method should depend on writing system in
addition to language convention
fantasai: The rest needs to be in the afternoon.
fantasai: I think andreyr had a selection issue?
Selections
==========
andreyr: We discussed this in Sophia, but fantasai put together
the spec. The grammar and spelling squiggly lines, we
wanted to control that color.
andreyr: We asked to add it to the spec. Any objections or
opinions?
florian: It was mentioned that there are security concerns, but it
can be handled as long as we're careful.
TabAtkins: You're limited to only color property things that don't
affect layout.
fantasai: Add ::spelling-error and ::grammar-error and have it
follow restrictions in layout model of ::selection and
add additional security verbiage.
<liam> [ is the squiggly line already a text-decoration value? ]
<astearns> liam: yes. wavy:
http://www.w3.org/TR/css-text-decor-3/#text-decoration-style-property
<SimonSapin> liam, yes, 'wavy'
http://dev.w3.org/csswg/css-text-decor/#propdef-text-decoration-style
<liam> [ thanks, although does this let you colour it differently
from the text?? ]
<SimonSapin> liam, text-decoration-color
plinss: Do we want a distinct pseudo-element or a functional one?
plinss: I'm just curious.
andreyr: I don't have an opinion.
fantasai: I don't have much of one. We already have ::selection.
plinss: I'm thinking of other uses like annotations. I'm wondering
if it's an extensibility point, or do we add more names?
fantasai: I think we're adding names either way. Spelling-error and
grammar-error need to be built-in.
plinss: Is it the full scope or a limited scope? [use functional
notation like :dir()] It's something to consider.
fantasai: Full pseudo-element space for now. If we find a need to
extract it we have time.
fantasai: There was discussion of having custom selections. That
would need to be encapsulated in a functional notation.
For these in the browser they won't be custom. Keeping
them out of the custom scope is a good idea.
fantasai: We won't be mixing custom and pseudo, which is a good
idea.
plinss: Adding to what?
TabAtkins: pseudo-elements
plinss: Wasn't pseudo-elements abandoned for a while?
TabAtkins: Didn't we just revive it?
fantasai: Yes. the plan is work in the meeting, do more testing,
then post to www-style, ask for reviews, and then ask
for FPWD.
SimonSapin: What are the security issues?
fantasai: :visited exposes history, this exposes your dictionary.
TabAtkins: It's a fingerprinting link.
plinss: We need to care about those. Also, in things like OSX your
address book gets added to your dictionary, so it's
definitely a security thing.
plinss: Even if you want to say fingerprinting is a lost cause,
you don't want to open the surface error. You don't want
to say I don't care about fingerprinting.
TabAtkins: But once I can be fingerprinted, more doesn't hurt.
plinss: It's a different set of values. And there are folks
working on fingerprinting.
CSS3 UI: text-overflow
======================
florian: It was pointed out yesterday we made a resolution on
ellipses with two values we said start/end instead of
left/right. Given that a fairly reasonable usage is
arrows, we may want absolute directions.
fantasai: That's why the spec currently has left/right.
florian: The other argument is there are some things that do flip.
fantasai: We have line-left and line-right. It should be physical
and Mozilla implemented that.
florian: It's that or let the author pick what he needs.
plinss: Are there use cases in both ways?
fantasai: I've seen ellipsis and arrow, I haven't seen start and
end differentiated.
florian: If you go with parentheses, they mirror, but you probably
don't want to. The reasonable use cases don't need that.
We could later have a syntax to let you say start/end.
florian: We also pointed out that it was inconsistent, but when
you have a value it applying to end makes sense.
florian: So it stays inconsistent. It's not clean but sounds
practical.
plinss: In my mind, I'm thinking when it shows up it's logical,
but which one we choose is physical.
fantasai: It depends on scroll position. Initial scroll state is
logical.
TabAtkins: It depends on if it's overflowing this end.
plinss: In the single value case you're not specifying the end,
it's just a value with where ever there's overflow.
florian: I think you specify end. I'm not sure you should, but
that's what it says.
plinss: So you explicitly don't get an ellipsis on the other side
if you only have one value. You never get one on the start
end.
florian: If there is one value it only applies to end line edge.
fantasai: Whatever is there is probably right.
plinss: Is that what we want?
fantasai: Given that the one value has a lot of use, we can't
change a whole lot. There's silliness already, like you
have to spec overflow not visible. That's the behavior
we're stuck with.
florian: So do we agree to replace yesterday's resolution with
line-left and line-right?
RESOLVED: Replace yesterday's resolution for start/end with
line-left and line-right
Counter Styles
==============
fantasai: It's in LC. Any open issues? If not, let's go to CR?
TabAtkins: One issue was about a handful of styles that browsers
have implemented but weren't in the draft since we cut
it down. I want to add the ones with high
interoperability.
TabAtkins: About 20 styles are implemented since they are
dependable for authors.
TabAtkins: The ones that aren't clear is the Tamil style, which is
only Firefox and this list:
<TabAtkins> afar, oromo, sidama, tigre
florian: For the 20 you talked about, you said reasonable, is that
2 or more implementations?
TabAtkins: 2 or more.
TabAtkins: The list above is supported by the browsers with roots
in webkit.
TabAtkins: My opinion is to not put them and recommend that
they're removed for consistency. It's still in the
original document. So, yea or nay on that. Keep the
ones that are implemented by more than one browser.
TabAtkins: I'll ask for removal with bugs.
plinss: Is that what we want?
TabAtkins: Yeah. If you do the author definition, you don't need
the one to be in Firefox.
plinss: Other opinions?
Bert: Can you repeat the ones you keep?
TabAtkins: It's long. If you find the list in the archives there's
a list from Richard Ishida of the additional values
supported by Firefox and webkit derived.
TabAtkins: All the values are in the spec right now.
TabAtkins: The ones that are only supported in one browser are in
the minutes above.
florian: Are we confident they're right?
TabAtkins: Richard has been testing and he's confident.
florian: We pushed them out because we aren't sure. Hopefully they
match what speakers would expect. If that's true I'm
happy with the spec.
TabAtkins: It's just listing them. They can be fixed in the future.
florian: One reason we're pushing in this direction is to avoid
time discussing languages we don't understand.
plinss: But it's not all browsers.
TabAtkins: Everybody but IE which is pretty close.
TabAtkins: If no one objects we can keep the list of 2+ browser
supported languages and not have the one browser
supported.
RESOLVED: Add to Counter Styles the additional styles supported by
2+ browsers (per r12a's email), do not add the styles
supported by only one browser.
TabAtkins: That's the only e-mail for counter styles since the LC
announcement.
TabAtkins: So given that I've made the change in the ED can we go
to CR?
Bert: Go for it!
TabAtkins: This has to be old process CR.
fantasai: I think you should be able to go into the new.
florian: We said it wasn't clear if you can do it with this.
TabAtkins: I think we can just do it.
plinss: I think the document says if you're in LC you cannot
switch to the new process.
fantasai: We've fulfilled the old process requirements.
plinss: Let's resolve to take counter styles to CR and go to the
new process if we can.
TabAtkins: So objections to publishing under some form of CR?
RESOLVED: Take counter styles to CR and go to the new process if
we can.
plinss: I propose we break until 2pm.
[lunch break until 2pm]
Bert: Is everyone here, shall we start?
Bert: I guess for Fonts we need jdaggett. Can someone ping him to
call?
TabAtkins: While we wait, Richard pointed out we didn't choose a
minimum time for CR for counter styles.
Bert: What time? Do we do 6 or 3 months?
TabAtkins: 3 months?
ChrisL: You can always take longer.
RESOLVED: 3 months for counter styles CR
Received on Friday, 2 January 2015 14:54:20 UTC