W3C home > Mailing lists > Public > www-style@w3.org > September 2015

[CSSWG] Minutes Paris F2F 2015-08-25 Part III: CSS UI 4, CSS Text 4, User Stylesheets [css-ui-4] [css-text-4]

From: Dael Jackson <daelcss@gmail.com>
Date: Fri, 4 Sep 2015 17:26:43 -0400
Message-ID: <CADhPm3sedx1XbnrU6288s_3m2zUyBe9j++JV+8PVvQW1Si=J5Q@mail.gmail.com>
To: www-style@w3.org

  - RESOLVED: Remove the note regarding user-select and
  - 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
  - RESOLVED: Publish FPWD of CSS UI 4

CSS Text 4

  - RESOLVED: Try option 1 in this e-mail:
  - 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


  scribe: dael


  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
  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
  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


  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
  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
  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
  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

  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
  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: 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
  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
  Florian: Yes, it lets us refer to several different ways of
  tantek: Sure, let's try it.

  Florian: So two resolutions to talk about hit testing and hot
  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.
  <zcorpan> we can add an inline issue about hit testing not being
  <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
  ChrisL: Can we resolve it now?
  fantasai: Maybe there was a proposed resolution with no final
  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
  Florian: Objections?

  RESOLVED: Add text-overflow: fade and let Florian figure out the

  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.


  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
  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
  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
  <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

  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
  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
  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

  RESOLVED: Try option 1 in this e-mail:

  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
  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
  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
  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
  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
  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
  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
  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
  <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
  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.


  <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

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