RE: User Stylesheets

I'm apparently one of the few who do use user stylesheets, and the lack of them in Chrome limits my use of Chrome. I did create a bookmarklet for Chrome that duplicates my Firefox/IE9 user stylesheet, but I have to click it each time I load a bothersome page. I don't want to install any extensions to Chrome because I want to keep it as pure as possible for security reasons.

I sometimes Inspect Element and alter the offending property (usually gray text, but also animation - even animation that lasts less than 5 seconds impacts me if it's happening over and over - parallax, or sites that use absolute positioning and assume a certain font size), but again I have to do that for each page and it's time-consuming.

I use the stylesheet to provide accessibility to websites that make it difficult for me to read.

The biggest shortcomings of user style sheets for me are:

1) Domain-specific support is spotty across browsers. 
2) It's time-consuming to toggle the user sheet on and off, as I need to be able to see the site I maintain the way others see it (for working on it) but I need to be able to see it my way for my day-to-day reading and content editing so I'm not squinting.

I acknowledge the education aspect. Altering the CSS of another website is *hard* and can cause things to break. But seriously, I care nothing about a website's pretty design if it stands in the way of my reading the content. For worst-case, I have a bookmarklet that wipes out all divs and CSS, although that often breaks interactivity.

If all websites were accessible, I wouldn't need user style sheets.

Hope this helps your discussion.

Charles Belov
Webmaster
San Francisco Municipal Transportation Agency
1 South Van Ness Avenue, 3rd Floor
San Francisco, CA 94103
Email: charles.belov@sfmta.com 
Phone: 415.701.4388
www.sfmta.com  
 

 Find us on:        

-----Original Message-----
From: Dael Jackson [mailto:daelcss@gmail.com] 
Sent: Friday, September 04, 2015 2:27 PM
To: www-style@w3.org
Subject: [CSSWG] Minutes Paris F2F 2015-08-25 Part III: CSS UI 4, CSS Text 4, User Stylesheets [css-ui-4] [css-text-4]
[[cbelov]] 

(snip)


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 Tuesday, 8 September 2015 19:49:34 UTC