- From: Dael Jackson <daelcss@gmail.com>
- Date: Fri, 4 Sep 2015 17:26:43 -0400
- To: www-style@w3.org
CSS UI 4
--------
- RESOLVED: Remove the note regarding user-select and
contenteditable
- RESOLVED: user-select: text stays named as-is
- RESOLVED: Drop all values except for 'auto' and 'none' on the
appearance property
- RESOLVED: Drop the all properties to do with caret animation
- RESOLVED: Clarify that we're using the hotspot to determine
which element is relevant
- RESOLVED: Depend on hit testing
- RESOLVED: Do not define hit testing
- RESOLVED: Add text-overflow: fade and let Florian figure out the
details
- RESOLVED: Publish FPWD of CSS UI 4
CSS Text 4
----------
- RESOLVED: Try option 1 in this e-mail:
https://lists.w3.org/Archives/Public/www-style/2015Jun/0099.html
- RESOLVED: text-space-trim, text-space-collapse, and text-wrap
are longhands of white-space and people can raise
issues if that's a problem.
- RESOLVED: FPWD for text 4
User Stylesheets
----------------
- There was general agreement that user stylesheets should stay in
the spec.
- There was interest in reviving @document
===== FULL MINUTES BELOW ======
scribe: dael
CSS UI 4
========
plinss: Let's get started
Florian: There's a few subtopics
Florian: TabAtkins sent a mail with some feedback that we can
address as a group
<hober> https://lists.w3.org/Archives/Public/www-style/2015Aug/0238.html
contenteditable and user-select:none
------------------------------------
Florian: There is a note... We added on a request from the WG a
note on user-select:none about how the combination of
that and contenteditable=true was supposed to behave
because there are use cases where this is reasonable and
we wanted to capture this requirement.
Florian: Given the way the editing TF is progressing I'm thinking
we should drop it because how it will be addressed.
Florian: There's no near-term plan to sync what every browser does
for contenteditable=true. However, what is happening is
there will be a number of events dispatch that will let a
JS react to anything that is happening and cancel if the
author wants something else to happen.
Florian: If they are editing the kind of JS we had in mind we
should do it. If they're doing something different, the
semantics in the note would not even apply.
Florian: If it belongs somewhere, it's there, but authors will be
able to do what they want to so we should drop the note.
Florian: I agree that it should be possible, but we don't tend to
put that in our specs.
tantek: It's an exception, not a rule.
Florian: Given where contenteditable is going, the note isn't
needed.
tantek: However we specify user-select, it allows the editing
folks to use it how they need to.
Florian: But the people writing the editing spec will not make it
behave any way. The JS authors will be able to control it.
If they're writing a code editor, they won't care about
this use case. It's not an evil note, I think it's not
applicable.
tantek: Then leave it out.
johanneswilm: As someone in the TF, the problem with the note is
that it's the only one aimed at JS editors, not
browser vendors. It would be new for JS.
johanneswilm: No matter where the note is, if you want to target
the old contenteditable then it makes sense. If you
want to target the new stuff, you're talking to the
JS editors who build this stuff. That's fine, but it
should be somewhere that pulls a bunch of things
about how to build a JS editor. The only reason JS
editors are reading this is to find bugs.
Florian: Proposal is to drop the note.
TabAtkins: Objection?
RESOLVED: Remove the note regarding user-select and contenteditable
user-select: contain
--------------------
Florian: We also discussed renaming user-select: element to
user-select:contain. We had general agreement, but I
think we were pending agreement from Microsoft.
Florian: You used element under a flag, we were waiting for you to
let us know.
user-select: text
-----------------
Florian: On a separate topic, we also mentioned that user-select:
text is terrible because it selects more than text, but
everyone supported that for a while. TabAtkins suggested
a new name.
TabAtkins: We can drop it for now.
RESOLVED: user-select: text stays named as-is
Appearance
----------
Florian: Another comment was they had reviewed appearance and it
was fine except they didn't want the button value.
Florian: The current version has none, auto, and a long series of
many values that are used to make form controls look the
way they should. There's been no success on synchronizing
browsers on that. The new appearance has none and auto
and just has magic for the form controls.
Florian: It's either none and you can't style or auto and you get
the magic. There's a handful of values that are useful,
for example button so you can say this link looks like a
button. I put that in there because I don't think it's a
crazy use case.
Florian: Microsoft also recently created support for -webkit's
appearance. I took that support as evidence that the web
needs it. Google doesn't like it.
tantek: Does Google support the back compat?
TabAtkins: And we're investigating the usage.
ojan: We'd like to drop as much as we can and whatever is left for
backcompat can go in the spec.
gregwhitworth: I have no interest in standardizing for backcompat
esprehn: It implies more than BG image. On mac there's padding and
windows it doesn't. There's a bunch of heuristic behavior
that's strange to spec.
Florian: If we spec appearance button, this lets an author opt
into appearing like a native button, whatever that means.
esprehn: For layout, is there a give me the padding that may be on
every platform. THat seems author hostile.
Florian: Except when the author asks for it.
gregwhitworth: We don't want to cement that.
tantek: I'd rather drop and spec a backcompat if necessary.
gregwhitworth: We often find when going from prefix to non-prefix
is to fix that.
dbaron: For backcompat we'll need to spec a lot of prefix
properties.
fantasai: If we have a prefix we need to have a path forward for
authors that want to move forward.
gregwhitworth: There's a clear path forward.
<zcorpan> https://github.com/search?l=css&q="appearance+button"&type=Code&;utf8=✓
github search for "appearance button"
Florian: I'm not married to the button value. If you want it off
I'm okay removing it. If Chrome is investigating what's
necessary we might as well wait.
fantasai: The reason not to use <button> is it doesn't behave like
a form.
TabAtkins: You wrap it in a form with the method=GET
plinss: I would rather not put in extra values until we've proven
we must have them.
tantek: Agreed.
Florian: I'm okay with that.
gregwhitworth: If you test our browser you'll find more, but
hopefully that's not a permanent thing.
Florian: So do we resolve to drop all the values except none or
auto?
gregwhitworth: I'm looking for bugs, but if we're doing them
they're in as stop gaps. There is a button tag.
Because it exists doesn't mean it has to be
standardized.
tantek: So let's drop everything except all and none.
plinss: Objections?
RESOLVED: Drop all values except for 'auto' and 'none' on the
appearance property
Caret Controls
--------------
Florian: A while back I put a blink time property which controls
how the caret blinks. I was told this was a bad idea and
we should explore this using CSS animations. Having
explored that, the conclusion was that's overkill. We
might just need caret-animation auto and none. TabAtkins
suggested fade. Just a limited list.
ChrisL: I don't like the animation model for caret being different
to the rest of animation.
Florian: If we have the property as specified now, caret animation
is auto by default. If you want to do something specific,
such as you don't want it to blink. If caret-color is a
color which exists you can't do animation.
Florian: There's a bunch of text editors that let you control
caret.
weinig: Does anyone let you control the caret? On windows?
gregwhitworth: We only have 3 values.
fantasai: If you have no blinking and the caret-color is
animate-able you can do anything you want.
Florian: Right now the caret-color can change to match the text. I
don't think we should work to make something stop working
that already does.
weinig: What's the use case for not blinking?
Florian: a11y
weinig: Then that's the browser that should control. It just seems
like a...
Florian: You said OSX doesn't have controls at the API? There's
terminal.
weinig: Terminal is non-standard. It's completely custom.
tantek: The only use case is a11y?
Florian: That's the main one. There's minor use cases for blinking
in and fading out. Like when you're doing retro things.
tantek: I think in those cases you rebuild your own caret.
hober: I think that the a11y is better as a system setting.
Florian: I think the homepages of 2 WG members have a blocky caret.
People are doing it and so it's out there.
TabAtkins: A number of text editors offer minor control over this.
Florian: There's a bunch of web text editors that would want to
behave like regular text editors. I think it would be
wrong...it's open ended. Having a limited set to choose
from, though, is good.
tantek: I don't think there's sufficient use case in this group. I
think we should punt to the editing task force and say if
you want it, you spec it. If you guys need it write the
requirement. Otherwise we'll drop it.
tantek: You cited web based text editors, so that's what made me
think of it.
fantasai: What if they come back and say let Florian spec this?
tantek: Then we cross that bridge.
johanneswilm: The main problem in some browsers is you couldn't
put anything on top of the caret. I don't know if
that's still the case, but it had an infinite-z. If
you could put something on top if it you could
animate to whatever.
fantasai: We can animate it (via caret-color), but that then
intersects with blinking.
johanneswilm: Editing has the major JS editors.
Florian: We don't have the people that write the code editors.
johanneswilm: We have them. Marijn Haverbeke wasn't at the
meeting, but he's on the task force.
Florian: How do you want that action/resolution to be phrased,
tantek?
tantek: We resolve that we drop the property. We action you to go
to the editing TF to ask if it's a requirement and to
document it if it is.
RESOLVED: drop the all properties to do with caret animation
ACTION Florian to figure out with the editing TF if there are and
what are the requirements for caret-animation
<trackbot> Created ACTION-705
<johanneswilm> Marijn Haverbeke (the person behind the CodeMirror
editor): CodeMirror's vim mode does use a custom
caret (in non-contentEditable
<johanneswilm> mode), which currently doesn't work in
contentEditable mode, so sure,
<johanneswilm> this would be nice to have. But that use case,
where the caret needs
<johanneswilm> to overlay the character after it, might be more
than browser vendor
<johanneswilm> are willing to chew. See http://codemirror.net/demo/vim.html
Cursor property's behavior when elements overlap is ambiguous
-------------------------------------------------------------
Florian: Next topic is this e-mail:
<Florian> https://lists.w3.org/Archives/Public/www-style/2015Aug/0010.html
Florian: We got a test case contributed that was trying to test
that if you set the cursor on the select element and you
set the cursor to something else on the parent of the
select element and you click and it shows the dropdown.
Some versions of IE show the parent. In general the spec
says what to do when cursor is in an element, but it
doesn't say anything about overlapping. We might need to
clarify and I don't know how to explain that.
Florian: So you're overlapping several things and this has
something to do with which thing would get the event if
you click, which we also don't define. It's definitely
undefined and would be worth clarifying if we could.
tantek: We've punted on this because it's hit testing.
Florian: So should I write nothing, or write that it depends on
the overlapping element.
tantek: I don't think you need to write a test case.
ChrisL: We've written tests to find out UA behavior to find out
how to spec it.
tantek: So we can accept the test. We've resolved not to accept
hit testing in UI 3 and I'd advise against it in 4.
ChrisL: I don't think this has to be hit testing. One thing we
should say is what part of the cursor has to be over
something.
tantek: That I'd be okay clarifying.
<tantek> that the hotspot of the cursor is what should be in the
border box.
ChrisL: The proposal from the guy wasn't sufficient. You've got
two items in a stacking context. Things can be overlapping
for different reasons. If there's two abspos elements we
know what's on top.
tantek: I don't want any hand waving about hit testing.
ChrisL: I said which renders on top.
zcorpan: If the cursor depends on hit testing, what appears on top
doesn't matter.
ChrisL: If we have 2 abspos elements we know what's on top.
Florian: Hit testing depends on what's on top and other things.
tantek: And you want it to matter, the hit testing.
Florian: Now the test was written because there was a disconnect
between the testing. IE had a version where the cursor
would click in the dropdown, but looked like the cursor
behind it. Even if we don't define hit testing we can
refer to it.
MaRakow: The cursor hit testing through the select dropdown was a
bug, not design.
Florian: I think we have a resolution that ChrisL said about using
hot spots.
ChrisL: I'd prefer to refer to hit testing.
tantek: I don't know how without opening a can of worms because
people will ask where to look for it.
Florian: Interoperability with hit testing is still something
worth striving for and specing eventually, but hit
testing is something that's used. However you do hit
testing, use that to pick the element for the cursor.
Florian: And then I can accept the test with spec justification.
Florian: So I'm tempted to put that in the spec.
tantek: So rather than leave it undefined, we refer to something
undefined?
Florian: Yes, it lets us refer to several different ways of
testing.
tantek: Sure, let's try it.
Florian: So two resolutions to talk about hit testing and hot
spots.
tantek: And to say the hot spot is what matters and in the case of
overlapping elements what's clicked is what counts, and to
not define that.
Florian: If we do that we can try and use the term.
<zcorpan> cssom view refers to hit testing in e.g.
https://drafts.csswg.org/cssom-view/#dom-document-elementfrompoint
<zcorpan> we can add an inline issue about hit testing not being
defined
<MaRakow> +1 zcorpan
Florian: Side question, can this be a way that UI level 4 is more
precise, or should this go in level 3? I think we can
just say level 4.
tantek: If it's a detail that there's interop, I think add it to
level 3. It's a clarification, not a CR breaking change.
Florian: I wouldn't want to break CR.
fantasai: You're in the new process. You're just republishing.
tantek: It's a clarification, not a significant change.
RESOLVED: Clarify that we're using the hotspot to determine which
element is relevant
<tantek> "within the element's border edge"
RESOLVED: Depend on hit testing
RESOLVED: Do not define hit testing
text-overflow: fade
-------------------
Florian: It was brought up with should have text-overflow: fade.
We have ellipsis, but if it's a line another desirable
effect is to fade to transparency.
Rossen: We have a resolution on this from Seoul. We added this,
you just need to add the text.
Florian: You're sure we resolved?
Rossen: I clearly remember we had the fade added to ellipsis.
astearns: We talked about it, but there was no resolution.
Rossen: There was the whole discussion about adding the pseudo
element.
ChrisL: Can we resolve it now?
fantasai: Maybe there was a proposed resolution with no final
resolution.
astearns: I don't see a proposed resolution in the minutes.
Florian: There was discussion about how long the fade should be.
tantek: Who was asking for this?
TabAtkins: Bloomberg.
Florian: And now there's someone else on the mailing list.
Bert: Can someone remind me, I wasn't there?
Florian: Instead of doing ... at the end, you would just fade out.
tantek: You would render the characters but where the ellipsis
would go, you would fade them out.
plinss: Rather than some random set of properties, I'd rather see
a pseudo element that can be styled
fantasai: I think we were planning to do that too, but this was a
stop-gap. You can insert content with the pseudo, not
remove it.
Florian: The pseudo matches the existing...
fantasai: There's no way to do this with existing properties. We
cannot just add a pseudo element to get this.
tantek: Do you have screenshots of this?
TabAtkins: Yeah, it's everywhere.
<Florian> http://snook.ca/archives/html_and_css/handling-overflow
andrey: The tabs in chrome do this is you have narrow enough text.
<leaverou> I'm not sure why we need to spec the fade. If we give
them an equivalent of -webkit-line-clamp, they can do
the fade themselves with a mask or pseudo element and
customize it as they want, no?
fantasai: Even if we added pseudo magic, we'd want a keyword for
common behaviors and this is clearly one of them.
Florian: CSS UI level 4 isn't near CR yet. I think we can resolve
to edit and I come back later with text. I'll read the
notes from the last meeting.
tantek: When does dino get here? When we talked about this in
Sydney, dino had particularly strong inputs on this.
hober: We basically do it in the location bar.
fantasai: They wanted more control over where the ellipsis happens.
That kind of thing is stuff they need, but we won't do
it immediately.
Florian: Can we resolve that we add it somehow or do we resolve
nothing? I think we agree that we want it.
fantasai: I think this makes sense to add. Even if we have a more
sophisticated mechanism we want to have a short keyword
to do this. I imagine this being a keyword to decide on
for whatever we do in the future. I'm in favor of adding
it.
Florian: Objections?
RESOLVED: Add text-overflow: fade and let Florian figure out the
details
Florian: With the exception of having not written the text for the
last resolution, I don't have intentions to add more to
CSS UI 4, so I think we should go to FPWD soonish. Does
anyone have a requirement of something they'd like to
have as a part of UI 4 that should be added?
ChrisL: If someone has a proposal they can do it for the next
draft. Let's go for it.
plinss: Objections?
RESOLVED: Publish FPWD of CSS UI 4
Florian: Does this let me publish now and add fade later?
plinss: Publish early, publish often.
fantasai: Do whatever you want.
dbaron: FPWD has implication on patent policy.
astearns: So better to put it in.
Florian: That's all for CSS UI today. You're all welcome to read
the doc.
css-text-4
==========
Florian: In New York we were discussing white-space: pre-wrap and
we resolved to add a pre-wrap-auto and for pre-wrap to
have a specific value and to add that to level 3. We also
resolved to add pre-wrap-trim to level 4 which would drop
the spaces at the end of the line. White-space is a
simple property in level 3, but a shorthand of two
properties in level 4.
Florian: So how is pre-wrap-auto and -trim related to these new
longhands?
fantasai: Didn't we resolve to seeing the spaces?
Florian: We discussed three. pre-wrap, pre-wrap-auto, and
pre-wrap-trim which drops the spaces at the end of the
line.
fantasai: Why are not use pre-line instead of pre-wrap-trim?
Florian: What we didn't discuss in New York is that white-space is
a shorthand of two longhands and I don't know how to
express that. I have two options. The new option 3 is
that the longhands were a bad idea and lets get rid of
them.
<Florian> https://lists.w3.org/Archives/Public/www-style/2015Jun/0099.html
Florian: So, first, do we want white-space to have long hands?
zcorpan: What's the use case for longhands?
fantasai: They seemed orthogonal considerations, but I don't
remember the exact use case for having them cascade
independently.
tantek: Did you have an option you prefer?
Florian: I've been back and forth. I think I prefer what I called
option 2 which is to not change text-space-collapse
property.
fantasai: I prefer option 1. But I can merge them back in.
fantasai: At this point we have 3 properties that are related.
There's text-space-collapse, text-space-trim, and
text-wrap.
Florian: And the reason it's tricky is with pre-wrap-auto things
aren't entirely orthogonal. The wrapping and collapsing
are not different concepts. If you do collapse the space
you won't wrap.
fantasai: I think option 1 makes more sense because how you wrap
depends on how you collapse, not the other way around.
fantasai: I'd be happy with option 1. As far as longhands or not,
they're very orthogonal things. If you ever want the set
to cascade independently, I'm not sure. But wrapping and
space collapsing are two independent variables.
Florian: So re-reading, I prefer option 1.
fantasai: Any other opinions?
tantek: I think we should try and make option 1 work and report
back if it doesn't.
fantasai: dbaron, can you have a shorthand that has inheriting and
non-inheriting properties?
dbaron: We haven't and I prefer not to, but it could be done.
We've done 'all'.
fantasai: I think text-space-trim should be in the white-space
shorthand as well. If you reset to normal it should do
all the normal things.
Florian: So, resolve option 1?
Florian: If we do that option 3 isn't excluded anymore. If we make
white-space: trim that that part is possible. It might be
an option, but it's not a good idea.
fantasai: No, that wouldn't work because you need it to inherit.
fantasai: I think we also have a conclusion that we need to add
the other two longhands of white-space if we're adding
white-space-trim
RESOLVED: Try option 1 in this e-mail:
https://lists.w3.org/Archives/Public/www-style/2015Jun/0099.html
fantasai: So should write-space-trim be added longhand which I
think yes.
astearns: It makes sense that white-space needs to be a shorthand.
I'm not sure we need the longhands.
fantasai: It needs to reset to normal.
Florian: So, astearns, are you saying pre-wrap-auto and trim
should not exist or only as longhands?
astearns: I'd prefer not to add any shorthand values unless
they're needed. We aren't going to add values to the
shorthand unless there's a demonstrated need.
Florian: For that I'd be okay for trim, but auto is justified on
the shorthand because it gets you browser behavior. Also
we have it on level 3 and there's no longhand on level 3.
Florian: So keep the behavior of white-space-trim but only on the
longhand. Is that okay with you, Bert?
Florian: We'd still have the behavior, but you need a longhand.
Bert: I'm not sure. I see you have the functionality, but I'm not
sure I want white-space to become a short hand. I don't have
a definite opinion.
Bert: It's at the level I want to spec things.
fantasai: New lines and spaces are in the same longhand. The first
one is how you collapse and the second is how you wrap.
fantasai: It allows you to set wrap independently of how you
collapse. I agree with you that the previous XSL had
three different properties and it was confusing.
Florian: With a bit of discomfort with the shorthands being linked
to different longhands with behavior...it's weird.
fantasai: Once place is where they get conflated is trim has a
trim inner value.
fantasai: If you're using discard-before and -after you might want
that cascaded separate. Or reset.
fantasai: I'm not sure and I don't feel too strongly about that.
Florian: But we're not on my issue anymore.
fantasai: I guess for simplicity let's group it under the
shorthand and if there's an issue people can raise it.
RESOLVED: text-space-trim, text-space-collapse, and text-wrap are
longhands of white-space and people can raise issues if
that's a problem.
Florian: astearns, I think a while ago you tried to get the WD out
of text level 4.
dauwhe: I'll probably have suggestions for features around
hyphenation.
fantasai: I've been told it's all wrong, but asked the person that
said that to list the issues on the ML and never heard
back.
plinss: Anything else on text?
Florian: Does this change if we should do FPWD?
fantasai: Go, we should.
RESOLVED: FPWD for text 4
User Stylesheets
================
ChrisL: There was some discussion about user stylesheets that
originated about customization. I did a twitter survey and
most people didn't know this feature exists. It's a
developer feature that we pretend is for users, but they
can't use it.
ChrisL: It seems to be a misfeature that's mostly, but not always
implemented. I think Chrome removed it.
TabAtkins: Yep. All we have is UA styles and page styles
<dino> Safari has them
<dino> you can pick one at a time
<dino> not really a great UI
ChrisL: I was asked if this feature is going to be extended or
deprecated by the group. I'm aware for some users that
need customization they're not using that mechanism. Do we
have any evidence it's being used? Should we leave it
alone? Should we drop and make something better?
ChrisL: I wanted to surface that discussion.
SimonSapin: There's a Firefox extension called Stylish that types
in CSS and I think it uses the user stylesheet.
ChrisL: Does it use our doc?
TabAtkins: Yes.
dbaron: It may or may not. We have user stylesheets for extensions.
I think we now have a per page one.
<dbaron> actually, not sure about the API; might just be thinking
about https://bugzilla.mozilla.org/show_bug.cgi?id=988266
ChrisL: A lot could have been done with user stylesheets and it
wasn't. For example bookmark could have used the
stylesheet. It could be a mechanism where people trade
their stylesheets.
Florian: There's nothing wrong with the design of user stylesheet.
What's been missing is a UI for this. I don't think it's
impossible, I think it hasn't been an important feature
for browsers.
Florian: I think you have something that lets you apply user
stylesheets. I think this is a good feature for a11y and
good for people who want to customize their stylesheet. I
think it's fine if people want to use it. Or here's a
variant of the developer tools. Let people experiment or
ignore.
hober: Chrome's behavior means that the user style is always just 0.
esprehn: There's little evidence that people want it. It's been in
Safari for years and people weren't using it, it wasn't
powerful enough. The Safari sheet applies to everything.
You want something powerful like stylish so you can have
if statements and the like. That might be out of scope.
ChrisL: That's one of the comments I got. When people want to
over-ride they want rules.
Florian: Once we have this, the rest is UI
ChrisL: And there's various things that use browser engines. If
they want per user they need it.
hober: We provide support for user stylesheets.
Florian: And one of the epubs that lets you change the background
uses it.
dauwhe: I think ebook is a huge use case. ebook developers right
now are putting a lot of work into trying to detect night
or day mode, there's a lot of work into that and lots of
misunderstandings.
dauwhe: I just hope for a wide API or something to make it easier
for ebooks.
Florian: It wouldn't be a JS API for web authors, it's for people
that edit the engine into a larger application.
Florian: I think we're missing that doc and UI innovation. It'll
always be a niche issue, but it's not ever used.
fantasai: Day and night mode, there's a spec for that.
astearns: Amazon isn't letting them use it, was dauwhe's point.
<fantasai> day/night spec - http://www.idpf.org/epub/altss-tags/
hober: I guess the question is, what is the ongoing burden of
retaining this.
Florian: I'd say 0.
hober: So there's some value to it and no reason to get rid of it.
esprehn: From our view this should be solved by UAs.
esprehn: We don't care about the spec. Chrome has an extension API
that lets you build this feature yourself and we support
authors building those tools because it will benefit devs.
The low level stylesheet facility is too complicated. The
people that want to use this want to pick a them.
hober: The point is user stylesheets have an implication for how
specificity is calculated. If we go into the spec and say
have some way to specify style, it's a loss.
Florian: Once we have a WG that standardizes browser extensions,
we don't need this.
esprehn: I don't believe we should standardize how browser
stylesheets interact with user stylesheets.
weinig: So my proposal was not to change the spec.
esprehn: We're not going to add it back.
tantek: It also represents preferences, such as the font. It's all
user stylesheets.
<fantasai> tantek++
TabAtkins: Some of those are not. What you want your serif to be
isn't represented that way.
TabAtkins: It's not true from Chrome, it never has been.
tantek: It was 15 years ago.
fantasai: You can't communicate the mapping of a font to the
generic serif family in CSS syntax.
tantek: I'm not saying that is, I'm saying that things like link
color are.
tantek: So if you have a thing that says pick a user stylesheet,
you still have to cascade like you have it.
dauwhe: There's lots of complaining in the ebook developer
community about how author and user stylesheets interact.
TabAtkins: I prefer having that control.
hober: It's unfortunately necessary.
Florian: Given that the difference between the browser not
implementing and implementing and not loading is the same
to the user, I think keeping it in the spec is the right
way.
ChrisL: So the conclusion is that it should stay in the spec. It
doesn't need changes or improvement.
Florian: I wouldn't say that. @document would make this more
useful. UAs that think it would be useful to expose this
to their users should innovate at the wide level. There
may be other ways that go through extensions, but that's
not a part of the WG.
ChrisL: That was the discussion I wanted to have.
Bert: Can we be more concrete about the @document? I'd like to see
it.
TabAtkins: It was in conditional rules
dbaron: It was dropped because there were parts we didn't know how
to spec and it was holding up the rest of the spec. We
might be able to do a better job with URL comparison, but
I think that was the main issue.
Florian: That was my memory.
<dauwhe> http://www.w3.org/TR/2011/WD-css3-conditional-20110901/#at-document
Bert: So we can spec this @document so I'd like to raise the
priority.
fantasai: Bert, would you volunteer to edit css-conditional-2?
hober: Anne has been working on adding a couple of comparison
functions to the URL spec.
SimonSapin: I believe these are compare an entire URL or a an URL
without the fragment.
TabAtkins: Also just the host.
hober: Someone should file a bug on the URL spec then.
weinig: What was the matching granularity intended to be? prefix?
dbaron: There were three in the spec. URL, URL prefix, and domain.
There's also regex in gecko. There's some issues with that.
That does go away if we don't expose it to author
stylesheets.
<leaverou> dbaron: "excluding any fragment identifiers"?! Why?
This could be very useful
weinig: Was it a full regex or a subset?
dbaron: Full as in calls the JS engine and tells it to deal with
it.
weinig: This is where your URL comparison question comes in, how
canonization is dealt with?
weinig: I don't think Anne's spec deals with regex but we may want
to ask them to deal with it.
<break=15min>
<zcorpan> <annevk> zcorpan: https://url.spec.whatwg.org/#url-equivalence
no API yet
<zcorpan> <annevk> zcorpan: if you have specific use cases, I
recommend filing issues
Received on Friday, 4 September 2015 21:27:45 UTC